Underwater Remotely Operated Vehicles at UW uwrovwiki https://uwrov.miraheze.org/wiki/Main_Page MediaWiki 1.40.1 first-letter Media Special Talk User User talk Underwater Remotely Operated Vehicles at UW Underwater Remotely Operated Vehicles at UW talk File File talk MediaWiki MediaWiki talk Template Template talk Help Help talk Category Category talk Module Module talk 0 1 1 2021-05-27T20:02:23Z MediaWiki default 1 Create main page wikitext text/x-wiki __NOTOC__ == Welcome to {{SITENAME}}! == This Main Page was automatically created by a wiki creator (a volunteer who created this wiki per a request), and it seems it hasn't been replaced yet. === For the bureaucrat(s) of this wiki === Hello, and welcome at your new wiki! Thank you for choosing Miraheze for the hosting of your wiki, and we hope you will enjoy our hosting. You can immediately start working on your wiki, whenever you want. Need help? No problem! We will help you with your wiki as needed. To make a start we have added a few links about working with MediaWiki: * <span class="plainlinks">[[mw:Special:MyLanguage/Help:Contents|MediaWiki guide (e.g. navigation, editing, deleting pages, blocking users)]] * [[meta:FAQ|Miraheze FAQ]] * [[meta:Request features|Request settings changes on your wiki. (Extensions and Logo/Favicon changes should be done through Special:ManageWiki on your wiki]]. ==== But Miraheze, I still don't understand X! ==== Well, that's no problem. Even if something isn't explained in the documentation/FAQ, we still are happy to help you. You can find us here: * [[meta:Help center|On our own Miraheze wiki]] * On [[phab:|Phabricator]] * On [https://miraheze.org/discord Discord] * On IRC in #miraheze on irc.libera.chat ([ircs://irc.libera.chat:6697/#miraheze direct link]; [https://kiwiirc.com/nextclient/irc.libera.chat/?channel=%23miraheze webchat]) === For a visitor of this wiki === Hello, the default Main Page of this wiki (this is the default Main Page) has not been replaced yet by the bureaucrat(s) of this wiki. The bureaucrat(s) might still be working on a Main Page, so please check this page again later! a9f76275482b198e10a221eee7c5d6b7554ad6ef 2 1 2021-09-04T21:44:39Z Uwrov 2 edit homepage wikitext text/x-wiki __NOTOC__ == Welcome to {{SITENAME}}! == Welcome to the UWROV wiki! * [[Software]] === Contributing to the Wiki === * <span class="plainlinks">[[mw:Special:MyLanguage/Help:Contents|MediaWiki guide (e.g. navigation, editing, deleting pages, blocking users)]] * [[meta:FAQ|Miraheze FAQ]] * [[meta:Request features|Request settings changes on your wiki. (Extensions and Logo/Favicon changes should be done through Special:ManageWiki on your wiki]]. ada34b0db9b1cbe2dc5e16874f28698db1f010b6 3 2 2021-09-04T21:50:38Z Gunarp 7 wikitext text/x-wiki __NOTOC__ == Welcome to {{SITENAME}}! == Welcome to the UWROV wiki! Check out our subteam wiki areas: * [[Software]] === Contributing to the Wiki === * <span class="plainlinks">[[mw:Special:MyLanguage/Help:Contents|MediaWiki guide (e.g. navigation, editing, deleting pages, blocking users)]] * [[meta:FAQ|Miraheze FAQ]] * [[meta:Request features|Request settings changes on your wiki. (Extensions and Logo/Favicon changes should be done through Special:ManageWiki on your wiki]]. 02196f029c2468ccab77d377b3b88d294928d79c 0 2 4 2021-09-04T22:26:01Z Gunarp 7 create software landing page wikitext text/x-wiki == Welcome to the Software Pages == ⌨🐒 * [[Quick Start]] * [[System Diagrams]] * [[Standards]] * [[Learning Resources]] 705ce52c0390c9fb1eeefab048c0290103b929f0 9 4 2021-09-16T01:52:50Z Gunarp 7 /* Welcome to the Software Pages */ wikitext text/x-wiki ⌨🐒 * [[Quick Start]] * [[System Diagrams]] * [[Standards]] * [[Learning Resources]] 7382ac3fd71cdb9ed33b597aa5e147c2ce1d7e71 12 9 2021-09-16T01:54:32Z Gunarp 7 wikitext text/x-wiki ⌨🐒 * [[Quick Start Guides]] * [[System Diagrams]] * [[Standards]] * [[Learning Resources]] e29c042dd13b946fb7703fb01e603aaca732b1e9 17 12 2021-09-16T01:58:09Z Gunarp 7 wikitext text/x-wiki ⌨🐒 * [[Software/Quick Start Guides|Quick Start Guides]] * [[System Diagrams]] * [[Standards]] * [[Learning Resources]] c168b9c725628a2dbd9f3e7846040764307ce466 19 17 2021-09-16T02:19:18Z Gunarp 7 wikitext text/x-wiki ⌨🐒 * [[Software/Quick Start Guides | Quick Start Guides]] * [[Software/System Diagrams | System Diagrams]] * [[Software/Standards | Standards]] * [[Software/Learning Resources | Learning Resources]] d729373f3161ee3e5fdbddefd0daffca407b7870 0 3 5 2021-09-16T01:46:09Z Gunarp 7 Add general info wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ''''' Organizational ''''' * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ''''' Technical ''''' * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== ''''' General ''''' * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes also used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusc]. b3b54a49e76bc507673ebc4a7aa4cc92cbea4d10 6 5 2021-09-16T01:47:51Z Gunarp 7 /* UWROV Software Team Overview */ wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ''''' Organizational ''''' * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ''''' Technical ''''' * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== ''''' General ''''' * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusc]. aa17ec67ceb102ce11e5ebb704ccd4709785d999 7 6 2021-09-16T01:50:10Z Gunarp 7 /* UWROV Software Team Overview */ wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusc]. 9f17fe12c713f6ea57ba92d9697ebe06381832d2 8 7 2021-09-16T01:51:48Z Gunarp 7 add in MATE wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. 54cfaa807f33d0931db48445aa9f806c00358440 10 8 2021-09-16T01:54:14Z Gunarp 7 Gunarp moved page [[Quick Start]] to [[Underwater Remotely Operated Vehicles at UW:Quick Start Guides]] wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. 54cfaa807f33d0931db48445aa9f806c00358440 13 10 2021-09-16T01:55:07Z Gunarp 7 Gunarp moved page [[Underwater Remotely Operated Vehicles at UW:Quick Start Guides]] to [[Quick Start Guides]] wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. 54cfaa807f33d0931db48445aa9f806c00358440 15 13 2021-09-16T01:56:12Z Gunarp 7 Gunarp moved page [[Quick Start Guides]] to [[Software/Quick Start Guides]] wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. 54cfaa807f33d0931db48445aa9f806c00358440 18 15 2021-09-16T01:59:53Z Gunarp 7 add in headers wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Docker Quick Start = = ROS Quick Start = = Interface Quick Start = = Development Quick Start = b2577ce37ad0c51547bc87a79d56f4166df0c4a1 22 18 2021-09-16T02:31:42Z Gunarp 7 /* Docker Quick Start */ wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Docker Quick Start = ==== Learning Resources ==== <nowiki>{{:Software/Learning Resources}}</nowiki> = ROS Quick Start = = Interface Quick Start = = Development Quick Start = abe32105f7c65e596ad3a1f951247722482fc028 23 22 2021-09-16T02:40:33Z Gunarp 7 /* Learning Resources */ wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Docker Quick Start = ==== Learning Resources ==== {{#lsth:Software/Learning Resources|Docker}} = ROS Quick Start = = Interface Quick Start = = Development Quick Start = 55cf000118fd5cf5caf0bc27a8259ca9989cb399 24 23 2021-09-16T02:49:44Z Gunarp 7 /* Docker Quick Start */ wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Docker Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Docker}} = ROS Quick Start = = Interface Quick Start = = Development Quick Start = 5f5c1ef17909aa331c1dc565e0fde04584409ca9 26 24 2021-09-16T02:51:49Z Gunarp 7 wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Docker Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Docker}} = ROS Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|ROS}} = Interface Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Interface}} = Git / Development Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Git}} 49926d2c398f49ef42cff208f8ccf1b0e3939e77 29 26 2021-09-16T03:16:45Z Gunarp 7 wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Docker Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Docker}} = ROS Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|ROS}} = Interface Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Interface}} = Development Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Development}} 23702491575f9d9223f5ececbe33124df9f6afe9 31 29 2021-09-16T03:18:10Z Gunarp 7 wikitext text/x-wiki = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Development Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Development}} = Docker Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Docker}} = ROS Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|ROS}} = Interface Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Interface}} 4866c2adae437fd16ad8cb8116647d1c8effd6f8 32 31 2021-09-16T03:20:11Z Gunarp 7 wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start guides to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Development Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Development}} = Docker Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Docker}} = ROS Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|ROS}} = Interface Quick Start = === Learning Resources === {{#lsth:Software/Learning Resources|Interface}} 9075799c5eeac275e556e87aebda860e933d2ab8 33 32 2021-09-16T03:23:08Z Gunarp 7 wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start guides to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Development Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Development}} = Docker Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Docker}} = ROS Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} = Interface Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} a5c163294bbc569cbaef9f2cb40945d79b76e0e5 34 33 2021-09-16T03:27:34Z Gunarp 7 add in subpages wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start guides to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! Alternatively, check out any guide on its own page! * [[Software/Quick Start Guides/UWROV Software Team Overview | Team Overview]]] * [[Software/Quick Start Guides/Development | Development]] * [[Software/Quick Start Guides/Docker | Docker]] * [[Software/Quick Start Guides/ROS | ROS]] * [[Software/Quick Start Guides/Interface | Interface]] = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Development Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Development}} = Docker Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Docker}} = ROS Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} = Interface Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} dae259046de53d75c308044de3e4510c555eaa1e 35 34 2021-09-16T03:27:46Z Gunarp 7 wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start guides to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! Alternatively, check out any guide on its own page! * [[Software/Quick Start Guides/UWROV Software Team Overview | Team Overview]] * [[Software/Quick Start Guides/Development | Development]] * [[Software/Quick Start Guides/Docker | Docker]] * [[Software/Quick Start Guides/ROS | ROS]] * [[Software/Quick Start Guides/Interface | Interface]] = UWROV Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. = Development Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Development}} = Docker Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Docker}} = ROS Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} = Interface Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} 1bd6860e2a474abaf86ad6e755dee3a95e9ab2bf 43 35 2021-09-16T03:31:32Z Gunarp 7 Put content in subpages wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start guides to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! Alternatively, check out any guide on its own page! * [[Software/Quick Start Guides/UWROV Software Team Overview | Team Overview]] * [[Software/Quick Start Guides/Development | Development]] * [[Software/Quick Start Guides/Docker | Docker]] * [[Software/Quick Start Guides/ROS | ROS]] * [[Software/Quick Start Guides/Interface | Interface]] = UWROV Software Team Overview = {{/UWROV Software Team Overview}} = Development Quick Start = {{/Development}} = Docker Quick Start = {{/Docker}} = ROS Quick Start = {{/ROS}} = Interface Quick Start = {{/Interface}} 8ddc8a369250b6f8a69d28c4d8e94d087ea7bbc9 44 43 2021-09-16T03:32:13Z Gunarp 7 Move headings into subpages wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start guides to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! Alternatively, check out any guide on its own page! * [[Software/Quick Start Guides/UWROV Software Team Overview | Team Overview]] * [[Software/Quick Start Guides/Development | Development]] * [[Software/Quick Start Guides/Docker | Docker]] * [[Software/Quick Start Guides/ROS | ROS]] * [[Software/Quick Start Guides/Interface | Interface]] {{/UWROV Software Team Overview}} {{/Development}} {{/Docker}} {{/ROS}} {{/Interface}} 811858f572394d0edf3590091c57974e3714f93b 0 4 11 2021-09-16T01:54:14Z Gunarp 7 Gunarp moved page [[Quick Start]] to [[Underwater Remotely Operated Vehicles at UW:Quick Start Guides]] wikitext text/x-wiki #REDIRECT [[Underwater Remotely Operated Vehicles at UW:Quick Start Guides]] 9aeb3fed6562a8a9fb1dd0e297715695fc919bc3 4 5 14 2021-09-16T01:55:08Z Gunarp 7 Gunarp moved page [[Underwater Remotely Operated Vehicles at UW:Quick Start Guides]] to [[Quick Start Guides]] wikitext text/x-wiki #REDIRECT [[Quick Start Guides]] ad96e2eefa75bfaa08e1371984e7437ee6884a28 0 6 16 2021-09-16T01:56:12Z Gunarp 7 Gunarp moved page [[Quick Start Guides]] to [[Software/Quick Start Guides]] wikitext text/x-wiki #REDIRECT [[Software/Quick Start Guides]] 49b4315b558e0ef53a7021c0b0a6dca1c498f5dc 0 7 20 2021-09-16T02:23:01Z Gunarp 7 docker links wikitext text/x-wiki = Git = = Docker = ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE | Docker basics (11 min video)] * [https://docs.docker.com/get-started/overview/ | Docker Overview] * [https://docs.docker.com/storage/volumes/ | Docker Volumes] * [https://docs.docker.com/storage/bind-mounts/ | Docker Bind Mounts] * [https://docs.docker.com/compose/ | Docker Compose] * [https://docs.docker.com/network/ | Docker Networking] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ | Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ | Docker Compose Reference] = ROS = 9af5aae4e5afd615d961950f1a55916f52eae978 21 20 2021-09-16T02:23:25Z Gunarp 7 /* Concepts */ wikitext text/x-wiki = Git = = Docker = ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] * [https://docs.docker.com/get-started/overview/ Docker Overview] * [https://docs.docker.com/storage/volumes/ Docker Volumes] * [https://docs.docker.com/storage/bind-mounts/ Docker Bind Mounts] * [https://docs.docker.com/compose/ Docker Compose] * [https://docs.docker.com/network/ Docker Networking] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ | Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ | Docker Compose Reference] = ROS = 04b5be613cb56caee47b75544755847d584cd136 25 21 2021-09-16T02:51:05Z Gunarp 7 wikitext text/x-wiki = Git = = Docker = ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] * [https://docs.docker.com/get-started/overview/ Docker Overview] * [https://docs.docker.com/storage/volumes/ Docker Volumes] * [https://docs.docker.com/storage/bind-mounts/ Docker Bind Mounts] * [https://docs.docker.com/compose/ Docker Compose] * [https://docs.docker.com/network/ Docker Networking] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ | Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ | Docker Compose Reference] = ROS = = Interface = e457a6cf3fa3a961994c145019021503d6755e67 27 25 2021-09-16T03:15:24Z Gunarp 7 add links for dev and ros wikitext text/x-wiki = Development = === Git === * [https://training.github.com/downloads/github-git-cheat-sheet/ Github Git Cheat Sheet] * [https://ndpsoftware.com/git-cheatsheet.html Visual Cheat Sheet] * [https://ohshitgit.com/ Oh shit git] - commands for some common mishaps === Unix === ==== Comprehensive Guides ==== * [http://www.ee.surrey.ac.uk/Teaching/Unix/ Unix Tutorial] * [https://courses.cs.washington.edu/courses/cse391/21su/ CSE 391 Archive] === Programming === TBA ==== Cheat sheet ==== * [https://files.fosswire.com/2007/08/fwunixref.pdf Command Cheat Sheet] = Docker = ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] * [https://docs.docker.com/get-started/overview/ Docker Overview] * [https://docs.docker.com/storage/volumes/ Docker Volumes] * [https://docs.docker.com/storage/bind-mounts/ Docker Bind Mounts] * [https://docs.docker.com/compose/ Docker Compose] * [https://docs.docker.com/network/ Docker Networking] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ Docker Compose Reference] = ROS = <noinclude>ROS has a weirdly high learning curve - there aren't a whole lot of 15 min explanations on it 😞</noinclude> ==== Walkthroughs ==== * [https://www.cse.sc.edu/~jokane/agitr/ A Gentle Introduction to ROS (Free Book)] * [http://wiki.ros.org/ROS/Tutorials ROS Tutorials] * [http://gazebosim.org/tutorials Gazebo Tutorials] = Interface = 841246fd1835504d3cbbc432095c866fb979497a 28 27 2021-09-16T03:15:46Z Gunarp 7 /* Development */ wikitext text/x-wiki = Development = === Git === * [https://training.github.com/downloads/github-git-cheat-sheet/ Github Git Cheat Sheet] * [https://ndpsoftware.com/git-cheatsheet.html Visual Cheat Sheet] * [https://ohshitgit.com/ Oh shit git] - commands for some common mishaps === Unix === ==== Comprehensive Guides ==== * [http://www.ee.surrey.ac.uk/Teaching/Unix/ Unix Tutorial] * [https://courses.cs.washington.edu/courses/cse391/21su/ CSE 391 Archive] ==== Cheat sheet ==== * [https://files.fosswire.com/2007/08/fwunixref.pdf Command Cheat Sheet] === Programming === TBA = Docker = ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] * [https://docs.docker.com/get-started/overview/ Docker Overview] * [https://docs.docker.com/storage/volumes/ Docker Volumes] * [https://docs.docker.com/storage/bind-mounts/ Docker Bind Mounts] * [https://docs.docker.com/compose/ Docker Compose] * [https://docs.docker.com/network/ Docker Networking] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ Docker Compose Reference] = ROS = <noinclude>ROS has a weirdly high learning curve - there aren't a whole lot of 15 min explanations on it 😞</noinclude> ==== Walkthroughs ==== * [https://www.cse.sc.edu/~jokane/agitr/ A Gentle Introduction to ROS (Free Book)] * [http://wiki.ros.org/ROS/Tutorials ROS Tutorials] * [http://gazebosim.org/tutorials Gazebo Tutorials] = Interface = adc923b69771da9708d04636701ec893297aabb7 30 28 2021-09-16T03:17:37Z Gunarp 7 wikitext text/x-wiki = Development = === Git === * [https://training.github.com/downloads/github-git-cheat-sheet/ Github Git Cheat Sheet] * [https://ndpsoftware.com/git-cheatsheet.html Visual Cheat Sheet] * [https://ohshitgit.com/ Oh shit git] - commands for some common mishaps === Unix === ==== Comprehensive Guides ==== * [http://www.ee.surrey.ac.uk/Teaching/Unix/ Unix Tutorial] * [https://courses.cs.washington.edu/courses/cse391/21su/ CSE 391 Archive] ==== Cheat sheet ==== * [https://files.fosswire.com/2007/08/fwunixref.pdf Command Cheat Sheet] === Programming === TBA = Docker = ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] - nice video which walks through some docker basics * [https://docs.docker.com/get-started/overview/ Docker Overview] * [https://docs.docker.com/storage/volumes/ Docker Volumes] * [https://docs.docker.com/storage/bind-mounts/ Docker Bind Mounts] * [https://docs.docker.com/compose/ Docker Compose] * [https://docs.docker.com/network/ Docker Networking] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ Docker Compose Reference] = ROS = <noinclude>ROS has a weirdly high learning curve - there aren't a whole lot of 15 min explanations on it 😞</noinclude> ==== Walkthroughs ==== * [https://www.cse.sc.edu/~jokane/agitr/ A Gentle Introduction to ROS (Free Book)] * [http://wiki.ros.org/ROS/Tutorials ROS Tutorials] * [http://gazebosim.org/tutorials Gazebo Tutorials] = Interface = 8f06d8b475c418b5e57187fdf62e96bb14e15648 50 30 2021-09-16T03:41:40Z Gunarp 7 add in more ros links wikitext text/x-wiki = Development = === Git === * [https://training.github.com/downloads/github-git-cheat-sheet/ Github Git Cheat Sheet] * [https://ndpsoftware.com/git-cheatsheet.html Visual Cheat Sheet] * [https://ohshitgit.com/ Oh shit git] - commands for some common mishaps === Unix === ==== Comprehensive Guides ==== * [http://www.ee.surrey.ac.uk/Teaching/Unix/ Unix Tutorial] * [https://courses.cs.washington.edu/courses/cse391/21su/ CSE 391 Archive] ==== Cheat sheet ==== * [https://files.fosswire.com/2007/08/fwunixref.pdf Command Cheat Sheet] === Programming === TBA = Docker = ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] - nice video which walks through some docker basics * [https://docs.docker.com/get-started/overview/ Docker Overview] * [https://docs.docker.com/storage/volumes/ Docker Volumes] * [https://docs.docker.com/storage/bind-mounts/ Docker Bind Mounts] * [https://docs.docker.com/compose/ Docker Compose] * [https://docs.docker.com/network/ Docker Networking] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ Docker Compose Reference] = ROS = <noinclude>ROS has a weirdly high learning curve - there aren't a whole lot of 15 min explanations on it 😞</noinclude> ==== Walkthroughs ==== * [https://www.cse.sc.edu/~jokane/agitr/ A Gentle Introduction to ROS (Free Book)] * [https://www.robotis.com/service/download.php?no=719 ROS Robot Programming (Another Free Book)] * [http://wiki.ros.org/ROS/Tutorials ROS Tutorials] * [http://gazebosim.org/tutorials Gazebo Tutorials] ==== Reference ==== * [https://github.com/leggedrobotics/ros_best_practices ROS Best Practices] - A nice example repo with a wiki with some general ideas to follow = Interface = 5ff176c5065528c6251dfc200a5e755e9d5cdc60 0 8 36 2021-09-16T03:28:13Z Gunarp 7 initial wikitext text/x-wiki === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. fa1b3b05bbab565dde019f9613ab1b13d9272a1b 49 36 2021-09-16T03:33:37Z Gunarp 7 wikitext text/x-wiki = Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. c8b8414a141569aa2a3d84812bd4ca97deb12eae 0 9 37 2021-09-16T03:29:36Z Gunarp 7 initial wikitext text/x-wiki Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Development}} = Docker Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Docker}} 6a8e042c6ddb7c62fef1ef19eb150e659d8c08af 38 37 2021-09-16T03:30:09Z Gunarp 7 Remove docker section wikitext text/x-wiki Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Development}} 031abfe58dacf01f2e52f3412dc1d2e0c8782973 45 38 2021-09-16T03:32:25Z Gunarp 7 wikitext text/x-wiki = Development = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Development}} 7c2a4426e5812b77b8f0b8222ba4631e9a7b30de 0 10 39 2021-09-16T03:30:14Z Gunarp 7 initial wikitext text/x-wiki = Docker Quick Start = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Docker}} a7eac0e17067b6a2e93104628d61fb24a6a74742 41 39 2021-09-16T03:30:49Z Gunarp 7 wikitext text/x-wiki Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Docker}} 632eccf9a792adad1e26d8d1ebd5a8d7ca8a2ea9 46 41 2021-09-16T03:32:36Z Gunarp 7 wikitext text/x-wiki = Docker = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Docker}} 93fbc8d62ca0a49490393d5cf9d1b6c272c04c60 0 11 40 2021-09-16T03:30:41Z Gunarp 7 intiial wikitext text/x-wiki Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} e1d00277739541db38e42da05605326ab0537cc8 47 40 2021-09-16T03:32:52Z Gunarp 7 wikitext text/x-wiki = ROS = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} 925e88ec6188674799e40e78d4ddd0177aa2ce38 0 12 42 2021-09-16T03:31:10Z Gunarp 7 initial wikitext text/x-wiki Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} 385e49ccdde40c4dc8660d8ee704c167f2896d8a 48 42 2021-09-16T03:33:02Z Gunarp 7 wikitext text/x-wiki = Interface = Quick sentence describing this section == Key Terms == == How to get started == == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} 7c7d5b3591d0c5b4a91398ee59bec9af25922219 0 11 51 47 2021-09-16T19:27:00Z Gunarp 7 first pass wikitext text/x-wiki = ROS = ROS (pronounced "ross" or "rozz") is short for ''R''obot ''O''perating ''S''ystem. ROS isn't an actual operating system like Windows or Mac OS, but rather a set of software libraries and tools which makes it feel like an operating system. The key things that ROS gives us are: * A package manager which lets us organize our code. * A robust communication library. * Simulation and Visualization tools. == Key Terms == ===== General ===== * '''ROS''' - Robot Operating System. ** '''ROS 2''' - A ground-up reimplementation of ROS with distributed robotics in mind. We are '''not''' using ROS 2 as more documentation currently exists for ROS 1. * '''Noetic''' - The version of ROS 1 we are currently using. * '''Package''' - Collection of code files which work towards a specific purpose. * '''Catkin''' - Build system used by ROS. ===== Communication ===== * '''Node''' - ROS handle on a running instance of a program. * '''Master''' - Node which manages all other nodes. * '''Topic''' - Channel where data can be written and read from. * '''Publisher''' - A mechanism a Node can use to write to a topic. * '''Subscriber''' - A mechanism a Node can use to read from a topic. ** '''Callback''' - A function a subscriber uses to process incoming data. ===== Simulation / Visualization ===== * '''Gazebo''' - Simulation program, independent from ROS but often used together. ** '''World''' - The simulation environment. ** '''Model''' - The objects in the world. * '''RViz''' - Visualization program, included with ROS. Not used in the club previously but could get into? == How to get started == # ? # ? # ? == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} 7a5fcbafd3114711673065021f1b772c6ca3274b 55 51 2021-09-16T20:01:50Z Gunarp 7 link to I need help page wikitext text/x-wiki = ROS = ROS (pronounced "ross" or "rozz") is short for ''R''obot ''O''perating ''S''ystem. ROS isn't an actual operating system like Windows or Mac OS, but rather a set of software libraries and tools which makes it feel like an operating system. The key things that ROS gives us are: * A package manager which lets us organize our code. * A robust communication library. * Simulation and Visualization tools. == I have a ROS question, who should I ask? == ROS can be really frustrating! So we'll try to help out however we can. First, review the "I need help" standards: {{#lst:Software/Standards/I need help|steps}} == Key Terms == ===== General ===== * '''ROS''' - Robot Operating System. ** '''ROS 2''' - A ground-up reimplementation of ROS with distributed robotics in mind. We are '''not''' using ROS 2 as more documentation currently exists for ROS 1. * '''Noetic''' - The version of ROS 1 we are currently using. * '''Package''' - Collection of code files which work towards a specific purpose. * '''Catkin''' - Build system used by ROS. ===== Communication ===== * '''Node''' - ROS handle on a running instance of a program. * '''Master''' - Node which manages all other nodes. * '''Message''' - Data type which can be * '''Topic''' - Channel where messages can be written and read from. * '''Publisher''' - A mechanism a Node can use to write to a topic. * '''Subscriber''' - A mechanism a Node can use to read from a topic. ** '''Callback''' - A function a subscriber uses to process incoming data. ===== Simulation / Visualization ===== * '''Gazebo''' - Simulation program, independent from ROS but often used together. ** '''World''' - The simulation environment. ** '''Model''' - The objects in the world. * '''RViz''' - Visualization program, included with ROS. Not used in the club previously but could get into? == How to get started == # ? # ? # ? == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} d88004615b1c86957561a9e2bb7f77154bd6b94b 56 55 2021-09-16T20:11:59Z Gunarp 7 add in people to tag wikitext text/x-wiki = ROS = ROS (pronounced "ross" or "rozz") is short for ''R''obot ''O''perating ''S''ystem. ROS isn't an actual operating system like Windows or Mac OS, but rather a set of software libraries and tools which makes it feel like an operating system. The key things that ROS gives us are: * A package manager which lets us organize our code. * A robust communication library. * Simulation and Visualization tools. == I have a ROS question, who should I ask? == ROS can be really frustrating! So we'll try to help out however we can. First, review the "I need help" standards: {{#lst:Software/Standards/I need help|steps}} Then, post a message in discord and tag someone. Here's a list of people you can tag for ROS / Simulation related issues: * Peter Gunarso (@Peter) * Laruen Krieger (@Lauren) * Bennedict Soesanto (@Bennedict) == Key Terms == ===== General ===== * '''ROS''' - Robot Operating System. ** '''ROS 2''' - A ground-up reimplementation of ROS with distributed robotics in mind. We are '''not''' using ROS 2 as more documentation currently exists for ROS 1. * '''Noetic''' - The version of ROS 1 we are currently using. * '''Package''' - Collection of code files which work towards a specific purpose. * '''Catkin''' - Build system used by ROS. ===== Communication ===== * '''Node''' - ROS handle on a running instance of a program. * '''Master''' - Node which manages all other nodes. * '''Message''' - Data type which can be * '''Topic''' - Channel where messages can be written and read from. * '''Publisher''' - A mechanism a Node can use to write to a topic. * '''Subscriber''' - A mechanism a Node can use to read from a topic. ** '''Callback''' - A function a subscriber uses to process incoming data. ===== Simulation / Visualization ===== * '''Gazebo''' - Simulation program, independent from ROS but often used together. ** '''World''' - The simulation environment. ** '''Model''' - The objects in the world. * '''RViz''' - Visualization program, included with ROS. Not used in the club previously but could get into? == How to get started == # ? # ? # ? == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} ec6476382f72ecce4ec5140678f6649683fcaf87 57 56 2021-09-16T20:13:05Z Gunarp 7 wikitext text/x-wiki = ROS = ROS (pronounced "ross" or "rozz") is short for ''R''obot ''O''perating ''S''ystem. ROS isn't an actual operating system like Windows or Mac OS, but rather a set of software libraries and tools which makes it feel like an operating system. The key things that ROS gives us are: * A package manager which lets us organize our code. * A robust communication library. * Simulation and Visualization tools. == I have a ROS question, who should I ask? == ROS can be really frustrating! So we'll try to help out however we can. First, review the [[Software/Standards/I need help | "I need help" standards]]: {{#lst:Software/Standards/I need help|steps}} Then, post a message in discord and tag someone. Here's a list of people you can tag for ROS / Simulation related issues: * Peter Gunarso (@Peter) * Laruen Krieger (@Lauren) * Bennedict Soesanto (@Bennedict) == Key Terms == ===== General ===== * '''ROS''' - Robot Operating System. ** '''ROS 2''' - A ground-up reimplementation of ROS with distributed robotics in mind. We are '''not''' using ROS 2 as more documentation currently exists for ROS 1. * '''Noetic''' - The version of ROS 1 we are currently using. * '''Package''' - Collection of code files which work towards a specific purpose. * '''Catkin''' - Build system used by ROS. ===== Communication ===== * '''Node''' - ROS handle on a running instance of a program. * '''Master''' - Node which manages all other nodes. * '''Message''' - Data type which can be * '''Topic''' - Channel where messages can be written and read from. * '''Publisher''' - A mechanism a Node can use to write to a topic. * '''Subscriber''' - A mechanism a Node can use to read from a topic. ** '''Callback''' - A function a subscriber uses to process incoming data. ===== Simulation / Visualization ===== * '''Gazebo''' - Simulation program, independent from ROS but often used together. ** '''World''' - The simulation environment. ** '''Model''' - The objects in the world. * '''RViz''' - Visualization program, included with ROS. Not used in the club previously but could get into? == How to get started == # ? # ? # ? == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} bd3cf41399e03c223df316006f546af88d8335f4 59 57 2021-09-16T20:17:26Z Gunarp 7 wikitext text/x-wiki = ROS = ROS (pronounced "ross" or "rozz") is short for ''R''obot ''O''perating ''S''ystem. ROS isn't an actual operating system like Windows or Mac OS, but rather a set of software libraries and tools which makes it feel like an operating system. The key things that ROS gives us are: * A package manager which lets us organize our code. * A robust communication library. * Simulation and Visualization tools. == I have a ROS question, who should I ask? == ROS can be really frustrating! So we'll try to help out however we can. {{#lst:Software/Standards/I need help|steps}} Then, post a message in discord and tag someone. Here's a list of people you can tag for ROS / Simulation related issues: * Peter Gunarso (@Peter) * Laruen Krieger (@Lauren) * Bennedict Soesanto (@Bennedict) == Key Terms == ===== General ===== * '''ROS''' - Robot Operating System. ** '''ROS 2''' - A ground-up reimplementation of ROS with distributed robotics in mind. We are '''not''' using ROS 2 as more documentation currently exists for ROS 1. * '''Noetic''' - The version of ROS 1 we are currently using. * '''Package''' - Collection of code files which work towards a specific purpose. * '''Catkin''' - Build system used by ROS. ===== Communication ===== * '''Node''' - ROS handle on a running instance of a program. * '''Master''' - Node which manages all other nodes. * '''Message''' - Data type which can be * '''Topic''' - Channel where messages can be written and read from. * '''Publisher''' - A mechanism a Node can use to write to a topic. * '''Subscriber''' - A mechanism a Node can use to read from a topic. ** '''Callback''' - A function a subscriber uses to process incoming data. ===== Simulation / Visualization ===== * '''Gazebo''' - Simulation program, independent from ROS but often used together. ** '''World''' - The simulation environment. ** '''Model''' - The objects in the world. * '''RViz''' - Visualization program, included with ROS. Not used in the club previously but could get into? == How to get started == # ? # ? # ? == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} 20e3084f715023c9bf896587346514cb7b8f7680 61 59 2021-09-16T20:19:16Z Gunarp 7 wikitext text/x-wiki = ROS = ROS (pronounced "ross" or "rozz") is short for ''R''obot ''O''perating ''S''ystem. ROS isn't an actual operating system like Windows or Mac OS, but rather a set of software libraries and tools which makes it feel like an operating system. The key things that ROS gives us are: * A package manager which lets us organize our code. * A robust communication library. * Simulation and Visualization tools. == I have a ROS question! == ROS can be really frustrating! So we'll try to help out however we can. {{#lst:Software/Standards/I need help|steps}} Then, post a message in discord and tag someone. Here's a list of people you can tag for ROS / Simulation related issues: * Peter Gunarso (@Peter) * Laruen Krieger (@Lauren) * Bennedict Soesanto (@Bennedict) == Key Terms == ===== General ===== * '''ROS''' - Robot Operating System. ** '''ROS 2''' - A ground-up reimplementation of ROS with distributed robotics in mind. We are '''not''' using ROS 2 as more documentation currently exists for ROS 1. * '''Noetic''' - The version of ROS 1 we are currently using. * '''Package''' - Collection of code files which work towards a specific purpose. * '''Catkin''' - Build system used by ROS. ===== Communication ===== * '''Node''' - ROS handle on a running instance of a program. * '''Master''' - Node which manages all other nodes. * '''Message''' - Data type which can be * '''Topic''' - Channel where messages can be written and read from. * '''Publisher''' - A mechanism a Node can use to write to a topic. * '''Subscriber''' - A mechanism a Node can use to read from a topic. ** '''Callback''' - A function a subscriber uses to process incoming data. ===== Simulation / Visualization ===== * '''Gazebo''' - Simulation program, independent from ROS but often used together. ** '''World''' - The simulation environment. ** '''Model''' - The objects in the world. * '''RViz''' - Visualization program, included with ROS. Not used in the club previously but could get into? == How to get started == # ? # ? # ? == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} 6828400325b174f1dd499b731dd2143f55bf0e47 72 61 2021-09-17T00:12:00Z Gunarp 7 wikitext text/x-wiki = ROS = ROS (pronounced "ross" or "rozz") is short for ''R''obot ''O''perating ''S''ystem. ROS isn't an actual operating system like Windows or Mac OS, but rather a set of software libraries and tools which makes it feel like an operating system. The key things that ROS gives us are: * A package manager which lets us organize our code. * A robust communication library. * Simulation and Visualization tools. == I have a ROS question! == ROS can be really frustrating! So we'll try to help out however we can. {{#lst:Software/Standards/I need help|steps}} Then, post a message in discord and tag someone. Here's a list of people you can tag for ROS / Simulation related issues: * Peter Gunarso (@Peter) * Laruen Krieger (@Lauren) * Bennedict Soesanto (@Bennedict) == Key Terms == ===== General ===== * '''ROS''' - Robot Operating System. ** '''ROS 2''' - A ground-up reimplementation of ROS with distributed robotics in mind. We are '''not''' using ROS 2 as more documentation currently exists for ROS 1. * '''Noetic''' - The version of ROS 1 we are currently using. * '''Package''' - Collection of code files which work towards a specific purpose. * '''Catkin''' - Build system used by ROS. ===== Communication ===== * '''Node''' - ROS handle on a running instance of a program. * '''Master''' - Node which manages all other nodes. * '''Message''' - Data type which can be * '''Topic''' - Channel where messages can be written and read from. * '''Publisher''' - A mechanism a Node can use to write to a topic. * '''Subscriber''' - A mechanism a Node can use to read from a topic. ** '''Callback''' - A function a subscriber uses to process incoming data. ===== Simulation / Visualization ===== * '''Gazebo''' - Simulation program, independent from ROS but often used together. ** '''World''' - The simulation environment. ** '''Model''' - The objects in the world. * '''RViz''' - Visualization program, included with ROS. Not used in the club previously but could get into? == Learning Resources == {{#lsth:Software/Learning Resources|ROS}} 837dbacca71de2bd921e6832ce61bb1f9dca9965 0 13 52 2021-09-16T19:40:32Z Gunarp 7 add page wikitext text/x-wiki [[/I need help | I need help]] f6fa247cd052d64683a5dd582d128015309bd03d 83 52 2021-09-21T02:49:11Z Gunarp 7 wikitext text/x-wiki [[/I need help | I need help]] [[/Git | Working with Git]] 94d30600a07e21ac483f4c5ed92bc037ad2bd03d 84 83 2021-09-21T02:49:23Z Gunarp 7 wikitext text/x-wiki * [[/I need help | I need help]] * [[/Git | Working with Git]] 45c8fe10507acc00446b8c0572080c1fdc7fdc0d 0 14 53 2021-09-16T19:57:56Z Gunarp 7 steps wikitext text/x-wiki We don't have a formal ticketing system, but when asking for help with something it'll be useful for both you and the person you're asking to have a good picture of what's going on. These aren't hard or fast rules, use your best judgement and you'll probably be fine. <section begin=help-steps/> # Describe what you're trying to do, and how you're trying to go about doing it. # Describe what went wrong, include screenshots or logs if possible. # If applicable, describe what approaches you've been trying to solve the problem. <section end=help-steps/> 27b4d29fec0740dce3d329c017cebc99d1bfaa7c 54 53 2021-09-16T19:59:37Z Gunarp 7 wikitext text/x-wiki We don't have a formal ticketing system, but when asking for help with something it'll be useful for both you and the person you're asking to have a good picture of what's going on. These aren't hard or fast rules, use your best judgement and you'll probably be fine. <section begin=steps/> # Describe what you're trying to do, and how you're trying to go about doing it. # Describe what went wrong, include screenshots or logs if possible. # If applicable, describe what approaches you've been trying to solve the problem. <section end=steps/> 602ab5c133890dd642d12f8fe5ab010a6a2e7022 58 54 2021-09-16T20:17:11Z Gunarp 7 add in includeonly link wikitext text/x-wiki We don't have a formal ticketing system, but when asking for help with something it'll be useful for both you and the person you're asking to have a good picture of what's going on. These aren't hard or fast rules, use your best judgement and you'll probably be fine. <section begin=steps/><includeonly>First, review the [[Software/Standards/I need help | "I need help" standards]]</includeonly> # Describe what you're trying to do, and how you're trying to go about doing it. # Describe what went wrong, include screenshots or logs if possible. # If applicable, describe what approaches you've been trying to solve the problem. <section end=steps/> 52367ff7210a89250ffd5617516b472193650e6e 60 58 2021-09-16T20:18:51Z Gunarp 7 wikitext text/x-wiki We don't have a formal ticketing system, but when asking for help with something it'll be useful for both you and the person you're asking to have a good picture of what's going on. These aren't hard or fast rules, use your best judgement and you'll probably be fine. <section begin=steps/><includeonly>First, review the [[Software/Standards/I need help | "I need help" standards]]</includeonly> # Describe what you're trying to do, and your general approach. # Detail the steps you took leading up to the issue you faced. # Describe what went wrong, include screenshots or logs if possible. # If applicable, describe what approaches you've been trying to solve the problem. <section end=steps/> 3dc0774a16a282663ac73ccae4352d54e388d26b 0 3 62 44 2021-09-16T20:24:13Z Gunarp 7 wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start references to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! Alternatively, check out any guide on its own page! * [[Software/Quick Start Guides/UWROV Software Team Overview | Team Overview]] * [[Software/Quick Start Guides/Development | Development]] * [[Software/Quick Start Guides/Docker | Docker]] * [[Software/Quick Start Guides/ROS | ROS]] * [[Software/Quick Start Guides/Interface | Interface]] {{/UWROV Software Team Overview}} {{/Development}} {{/Docker}} {{/ROS}} {{/Interface}} 957b40b5ec48fee763557647a6541bdbdfabe515 65 62 2021-09-16T21:44:46Z Gunarp 7 swap order of sections wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start references to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! Alternatively, check out any guide on its own page! * [[Software/Quick Start Guides/UWROV Software Team Overview | Team Overview]] * [[Software/Quick Start Guides/Development | Development]] * [[Software/Quick Start Guides/Interface | Interface]] * [[Software/Quick Start Guides/ROS | ROS]] * [[Software/Quick Start Guides/Docker | Docker]] {{/UWROV Software Team Overview}} {{/Development}} {{/Interface}} {{/Docker}} {{/ROS}} f972dac1e61f9fc74b40afb0bbc3eb9c647566c8 67 65 2021-09-16T22:02:12Z Gunarp 7 remove docker section wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start references to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! Alternatively, check out any guide on its own page! * [[Software/Quick Start Guides/UWROV Software Team Overview | Team Overview]] * [[Software/Quick Start Guides/Development | Development]] * [[Software/Quick Start Guides/Interface | Interface]] * [[Software/Quick Start Guides/ROS | ROS]] {{/UWROV Software Team Overview}} {{/Development}} {{/Interface}} {{/ROS}} f535383f365ebf2a269949619435f0420e893337 0 2 63 19 2021-09-16T20:50:29Z Gunarp 7 wikitext text/x-wiki 💻🐒 * [[Software/Quick Start Guides | Quick Start Guides]] * [[Software/System Diagrams | System Diagrams]] * [[Software/Standards | Standards]] * [[Software/Learning Resources | Learning Resources]] f0d6270e036d5fb7cabc3dc103e746a2b290a8da 64 63 2021-09-16T21:05:10Z Gunarp 7 wikitext text/x-wiki 💻🐒 * [[Software/Quick Start Guides | Quick Start Guides]] * [[Software/System | System]] * [[Software/Standards | Standards]] * [[Software/Learning Resources | Learning Resources]] bd20aef5121ad01e3641f3397862123cc7b9932f 82 64 2021-09-21T02:48:39Z Gunarp 7 add link to tutorial wikitext text/x-wiki 💻🐒 * [[Software/Quick Start Guides | Quick Start Guides]] * [[Software/Starting Tutorial | Development Tutorial]] * [[Software/System | System]] * [[Software/Standards | Standards]] * [[Software/Learning Resources | Learning Resources]] c01edcf1b4a1bfec5a909126af4da99fba151cf8 0 7 66 50 2021-09-16T22:01:57Z Gunarp 7 remove docker section wikitext text/x-wiki = Development = === Git === * [https://training.github.com/downloads/github-git-cheat-sheet/ Github Git Cheat Sheet] * [https://ndpsoftware.com/git-cheatsheet.html Visual Cheat Sheet] * [https://ohshitgit.com/ Oh shit git] - commands for some common mishaps === Unix === ==== Comprehensive Guides ==== * [http://www.ee.surrey.ac.uk/Teaching/Unix/ Unix Tutorial] * [https://courses.cs.washington.edu/courses/cse391/21su/ CSE 391 Archive] ==== Cheat sheet ==== * [https://files.fosswire.com/2007/08/fwunixref.pdf Command Cheat Sheet] === Docker === ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] - nice video which walks through some docker basics * [https://docs.docker.com/get-started/overview/ Docker Overview] * [https://docs.docker.com/storage/volumes/ Docker Volumes] * [https://docs.docker.com/storage/bind-mounts/ Docker Bind Mounts] * [https://docs.docker.com/compose/ Docker Compose] * [https://docs.docker.com/network/ Docker Networking] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ Docker Compose Reference] === Programming === TBA = ROS = <noinclude>ROS has a weirdly high learning curve - there aren't a whole lot of 15 min explanations on it 😞</noinclude> ==== Walkthroughs ==== * [https://www.cse.sc.edu/~jokane/agitr/ A Gentle Introduction to ROS (Free Book)] * [https://www.robotis.com/service/download.php?no=719 ROS Robot Programming (Another Free Book)] * [http://wiki.ros.org/ROS/Tutorials ROS Tutorials] * [http://gazebosim.org/tutorials Gazebo Tutorials] ==== Reference ==== * [https://github.com/leggedrobotics/ros_best_practices ROS Best Practices] - A nice example repo with a wiki with some general ideas to follow = Interface = c351799e1da1a62b4abe5a0b8d28b0769327f4ca 68 66 2021-09-16T22:02:42Z Gunarp 7 swap section order wikitext text/x-wiki = Development = === Git === * [https://training.github.com/downloads/github-git-cheat-sheet/ Github Git Cheat Sheet] * [https://ndpsoftware.com/git-cheatsheet.html Visual Cheat Sheet] * [https://ohshitgit.com/ Oh shit git] - commands for some common mishaps === Unix === ==== Comprehensive Guides ==== * [http://www.ee.surrey.ac.uk/Teaching/Unix/ Unix Tutorial] * [https://courses.cs.washington.edu/courses/cse391/21su/ CSE 391 Archive] ==== Cheat sheet ==== * [https://files.fosswire.com/2007/08/fwunixref.pdf Command Cheat Sheet] === Docker === ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] - nice video which walks through some docker basics * [https://docs.docker.com/get-started/overview/ Docker Overview] * [https://docs.docker.com/storage/volumes/ Docker Volumes] * [https://docs.docker.com/storage/bind-mounts/ Docker Bind Mounts] * [https://docs.docker.com/compose/ Docker Compose] * [https://docs.docker.com/network/ Docker Networking] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ Docker Compose Reference] === Programming === TBA = Interface = = ROS = <noinclude>ROS has a weirdly high learning curve - there aren't a whole lot of 15 min explanations on it 😞</noinclude> ==== Walkthroughs ==== * [https://www.cse.sc.edu/~jokane/agitr/ A Gentle Introduction to ROS (Free Book)] * [https://www.robotis.com/service/download.php?no=719 ROS Robot Programming (Another Free Book)] * [http://wiki.ros.org/ROS/Tutorials ROS Tutorials] * [http://gazebosim.org/tutorials Gazebo Tutorials] ==== Reference ==== * [https://github.com/leggedrobotics/ros_best_practices ROS Best Practices] - A nice example repo with a wiki with some general ideas to follow 212e2f37be6eb37eec928bc25e2013d726d6cb7b 69 68 2021-09-16T22:12:50Z Gunarp 7 remove some docker links wikitext text/x-wiki = Development = === Git === * [https://training.github.com/downloads/github-git-cheat-sheet/ Github Git Cheat Sheet] * [https://ndpsoftware.com/git-cheatsheet.html Visual Cheat Sheet] * [https://ohshitgit.com/ Oh shit git] - commands for some common mishaps === Unix === ==== Comprehensive Guides ==== * [http://www.ee.surrey.ac.uk/Teaching/Unix/ Unix Tutorial] * [https://courses.cs.washington.edu/courses/cse391/21su/ CSE 391 Archive] ==== Cheat sheet ==== * [https://files.fosswire.com/2007/08/fwunixref.pdf Command Cheat Sheet] === Docker === ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] - nice video which walks through some docker basics * [https://docs.docker.com/get-started/overview/ Docker Overview] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ Docker Compose Reference] === Programming === TBA = Interface = = ROS = <noinclude>ROS has a weirdly high learning curve - there aren't a whole lot of 15 min explanations on it 😞</noinclude> ==== Walkthroughs ==== * [https://www.cse.sc.edu/~jokane/agitr/ A Gentle Introduction to ROS (Free Book)] * [https://www.robotis.com/service/download.php?no=719 ROS Robot Programming (Another Free Book)] * [http://wiki.ros.org/ROS/Tutorials ROS Tutorials] * [http://gazebosim.org/tutorials Gazebo Tutorials] ==== Reference ==== * [https://github.com/leggedrobotics/ros_best_practices ROS Best Practices] - A nice example repo with a wiki with some general ideas to follow 759d501a03963a52c46a977018609f195ed183a7 92 69 2021-09-21T21:50:39Z Ajang304 9 /* Interface */ wikitext text/x-wiki = Development = === Git === * [https://training.github.com/downloads/github-git-cheat-sheet/ Github Git Cheat Sheet] * [https://ndpsoftware.com/git-cheatsheet.html Visual Cheat Sheet] * [https://ohshitgit.com/ Oh shit git] - commands for some common mishaps === Unix === ==== Comprehensive Guides ==== * [http://www.ee.surrey.ac.uk/Teaching/Unix/ Unix Tutorial] * [https://courses.cs.washington.edu/courses/cse391/21su/ CSE 391 Archive] ==== Cheat sheet ==== * [https://files.fosswire.com/2007/08/fwunixref.pdf Command Cheat Sheet] === Docker === ==== Concepts ==== * [https://www.youtube.com/watch?v=gAkwW2tuIqE Docker basics (11 min video)] - nice video which walks through some docker basics * [https://docs.docker.com/get-started/overview/ Docker Overview] ==== Reference ==== * [https://docs.docker.com/engine/reference/builder/ Dockerfile Reference] * [https://docs.docker.com/compose/compose-file/compose-file-v3/ Docker Compose Reference] === Programming === TBA = Interface = [https://reactjs.org/tutorial/tutorial.html React tutorial] <br/> [https://socket.io/docs/v4/ Socket.io docs] = ROS = <noinclude>ROS has a weirdly high learning curve - there aren't a whole lot of 15 min explanations on it 😞</noinclude> ==== Walkthroughs ==== * [https://www.cse.sc.edu/~jokane/agitr/ A Gentle Introduction to ROS (Free Book)] * [https://www.robotis.com/service/download.php?no=719 ROS Robot Programming (Another Free Book)] * [http://wiki.ros.org/ROS/Tutorials ROS Tutorials] * [http://gazebosim.org/tutorials Gazebo Tutorials] ==== Reference ==== * [https://github.com/leggedrobotics/ros_best_practices ROS Best Practices] - A nice example repo with a wiki with some general ideas to follow d1801452f3130728e0e31f2991de3f36898e3ca8 0 9 70 45 2021-09-16T22:48:32Z Gunarp 7 first pass wikitext text/x-wiki = Development = This is a super broad section which is meant to cover some of the miscellaneous development tools that we're using. Use this section as a ''reference'', don't worry about trying to get everything memorized on your first pass. == Key Terms == === Git === * '''Git''' - A version control system, allows us to share code "easily." * '''Repo''' - Short for repository, a place where git manages a code store. ** '''local''' - A local repo is one you maintain on your computer. ** '''remote''' - A remote repo is located outside your computer. The remote you'll typically see is the one on GitHub. * '''Commit''' - Basic unit of work in Git, represents a change to the repository. * '''Merge''' - Process of combining local and remote changes. * '''Branch''' - An independent line of development within a repo. * '''Pull Request''' - An item opened on GitHub to the contents of one branch into another. === Unix === * '''File''' - A computing resource which holds data. * '''Directory''' - A file which holds other files. * '''Process''' - A runtime environment of a program, managed by the operating system. * '''Thread''' - A sequence of program instruction executions, managed by a process. One process can have many threads. === Docker === * '''Dockerfile''' - * '''Image''' - * '''Container''' - === Programming === == How to get started == # Make sure you have access to the GitHub. == Learning Resources == {{#lsth:Software/Learning Resources|Development}} 4557d108571fe0debdfbe8a2f61dbd2ea4cc6074 73 70 2021-09-17T00:12:12Z Gunarp 7 wikitext text/x-wiki = Development = This is a super broad section which is meant to cover some of the miscellaneous development tools that we're using. Use this section as a ''reference'', don't worry about trying to get everything memorized on your first pass. == Key Terms == === Git === * '''Git''' - A version control system, allows us to share code "easily." * '''Repo''' - Short for repository, a place where git manages a code store. ** '''local''' - A local repo is one you maintain on your computer. ** '''remote''' - A remote repo is located outside your computer. The remote you'll typically see is the one on GitHub. * '''Commit''' - Basic unit of work in Git, represents a change to the repository. * '''Merge''' - Process of combining local and remote changes. * '''Branch''' - An independent line of development within a repo. * '''Pull Request''' - An item opened on GitHub to the contents of one branch into another. === Unix === * '''File''' - A computing resource which holds data. * '''Directory''' - A file which holds other files. * '''Process''' - A runtime environment of a program, managed by the operating system. * '''Thread''' - A sequence of program instruction executions, managed by a process. One process can have many threads. === Docker === * '''Dockerfile''' - * '''Image''' - * '''Container''' - === Programming === == Learning Resources == {{#lsth:Software/Learning Resources|Development}} d4ab0e5e0c975fe62121d5352e33ef3bbaf3bcb5 74 73 2021-09-17T17:35:31Z Gunarp 7 add some key terms for docker wikitext text/x-wiki = Development = This is a super broad section which is meant to cover some of the miscellaneous development tools that we're using. Use this section as a ''reference'', don't worry about trying to get everything memorized on your first pass. == Key Terms == === Git === * '''Git''' - A version control system, allows us to share code "easily." * '''Repo''' - Short for repository, a place where git manages a code store. ** '''local''' - A local repo is one you maintain on your computer. ** '''remote''' - A remote repo is located outside your computer. The remote you'll typically see is the one on GitHub. * '''Commit''' - Basic unit of work in Git, represents a change to the repository. * '''Merge''' - Process of combining local and remote changes. * '''Branch''' - An independent line of development within a repo. * '''Pull Request''' - An item opened on GitHub to the contents of one branch into another. === Unix === * '''File''' - A computing resource which holds data. * '''Directory''' - A file which holds other files. * '''Process''' - A runtime environment of a program, managed by the operating system. * '''Thread''' - A sequence of program instruction executions, managed by a process. One process can have many threads. === Docker === * '''Dockerfile''' - A set of instructions Docker uses to build an image. * '''Image''' - An immutable file which describes a container's environment. * '''Container''' - A runtime of an image. Think of it like a lightweight virtual machine. * '''Compose''' - Software from Docker to build and run multiple containers on one host. === Programming === == Learning Resources == {{#lsth:Software/Learning Resources|Development}} ddf6856cab51adef1141c8896051ed5c90b7d7b3 0 12 71 48 2021-09-17T00:11:47Z Gunarp 7 wikitext text/x-wiki = Interface = Quick sentence describing this section == Key Terms == == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} 49d00dff3c2cb96de85a4eb166597089b1a92bb3 85 71 2021-09-21T19:05:20Z Ajang304 9 /* Interface */ wikitext text/x-wiki = Interface = The interface is a react based interface that runs on Node.js. The interface consists of two main parts: the widget management system and individual widgets. The interface can be expanded in functionality by creating modular widgets that can be added as miniature windows on the interface. == Key Terms == React: library to manage our UI lifecycle Socket.io: library for network calls between interface and servers == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} d830a858dd02bbd8d7ec36ead22fac0729b05821 86 85 2021-09-21T19:05:55Z Ajang304 9 /* Key Terms */ wikitext text/x-wiki = Interface = The interface is a react based interface that runs on Node.js. The interface consists of two main parts: the widget management system and individual widgets. The interface can be expanded in functionality by creating modular widgets that can be added as miniature windows on the interface. == Key Terms == React: library to manage our UI lifecycle <br> Socket.io: library for network calls between interface and servers == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} 3fd9b7b4b73122010a98f94df9344d1cc349a60f 87 86 2021-09-21T19:14:00Z Ajang304 9 /* Learning Resources */ wikitext text/x-wiki = Interface = The interface is a react based interface that runs on Node.js. The interface consists of two main parts: the widget management system and individual widgets. The interface can be expanded in functionality by creating modular widgets that can be added as miniature windows on the interface. == Key Terms == React: library to manage our UI lifecycle <br> Socket.io: library for network calls between interface and servers == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} [https://reactjs.org/tutorial/tutorial.html React tutorial] [https://socket.io/docs/v4/ socket.io docs] ac89394be447d6286edf088724e28e7c348f408b 88 87 2021-09-21T19:14:15Z Ajang304 9 /* Learning Resources */ wikitext text/x-wiki = Interface = The interface is a react based interface that runs on Node.js. The interface consists of two main parts: the widget management system and individual widgets. The interface can be expanded in functionality by creating modular widgets that can be added as miniature windows on the interface. == Key Terms == React: library to manage our UI lifecycle <br> Socket.io: library for network calls between interface and servers == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} [https://reactjs.org/tutorial/tutorial.html React tutorial] <br/> [https://socket.io/docs/v4/ socket.io docs] 5acbdd59b20ace503597471abff404eae05c9968 89 88 2021-09-21T19:14:32Z Ajang304 9 /* Learning Resources */ wikitext text/x-wiki = Interface = The interface is a react based interface that runs on Node.js. The interface consists of two main parts: the widget management system and individual widgets. The interface can be expanded in functionality by creating modular widgets that can be added as miniature windows on the interface. == Key Terms == React: library to manage our UI lifecycle <br> Socket.io: library for network calls between interface and servers == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} [https://reactjs.org/tutorial/tutorial.html React tutorial] <br/> [https://socket.io/docs/v4/ Socket.io docs] 821ff9be8b84082073ec97956ce1a72168772319 93 89 2021-09-21T21:51:24Z Ajang304 9 /* Learning Resources */ wikitext text/x-wiki = Interface = The interface is a react based interface that runs on Node.js. The interface consists of two main parts: the widget management system and individual widgets. The interface can be expanded in functionality by creating modular widgets that can be added as miniature windows on the interface. == Key Terms == React: library to manage our UI lifecycle <br> Socket.io: library for network calls between interface and servers == Learning Resources == {{#lsth:Software/Learning Resources|Interface}} 3fd9b7b4b73122010a98f94df9344d1cc349a60f 0 8 75 49 2021-09-17T18:04:35Z Gunarp 7 add getting started links wikitext text/x-wiki = Software Team Overview = === Software Leads === * Andrew Jang (he/him), @Andrew on discord * Lauren Krieger (she/her), @Lauren on discord * Peter Gunarso (he/him), @Peter on discord ===I have a question, who do I ask?=== Post any general or technical questions in a relevant channel in the discord - feel free to tag someone too! <br/> If you have a more personal issue please send a message to one of the leads. ===What does the software team do?=== We create and maintain the software necessary for our ROV to complete its tasks. To jump into some specific projects our team owns: * A mostly user-friendly control system to pilot the ROV * Software to accomplish specific mission tasks, which often cover CV and Autonomy * Software to interact with the hardware onboard the ROV * Club website ===What tools do we use?=== ===== Organizational ===== * Project Management: [https://uwrov.monday.com/ monday.com] * Documentation: Miraheze (highest level), GitHub READMEs (mid level), code (low level) * Drafting / Note Taking: Google Drive * Communication: Discord ===== Technical ===== * Editor: You can use whatever editor you're most comfortable with. Recommended: [https://code.visualstudio.com/ VSCode] * Containers: Docker and Docker Compose * Onboard Computer: Raspberry Pi ===Some good key terms to know=== * '''UWROV''' - ''U''nder''W''ater ''R''emotely ''O''perated ''V''ehicles. * '''ROV''' - Remotely Operated Vehicle. Usually in reference to the ROV we build. ** '''Robot''' - Sometimes used in place of ROV. * '''Nautilus''' - The name of the ROV created for the 2020-2021 season. Named after the [https://en.wikipedia.org/wiki/Nautilus mollusk]. * '''MATE''' - The name of the organization which organizes the [https://materovcompetition.org/ competition]. == Getting Started == # Review the [[/Checklist | New Member Checklist]]. # Follow the [[Software/Starting Tutorial | Starting Tutorial]] 476f6f4a84f7c335de130d7c9767efba31c64196 0 15 76 2021-09-17T18:30:07Z Gunarp 7 skeleton wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll == Setting up Docker == Before we get === Installation === === Running the container === == ROS package == === Create a new package === === Create a publisher === === Verify the publisher works === Use <code>rostopic echo /nautilus/text</code> = Add a Component to the Interface = === Create a subscriber === === Send messages to the interface === === Create an interface component === And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! f61ac655aed57c1156200c4259e870c45a748fa5 77 76 2021-09-17T18:31:24Z Gunarp 7 add descriptors wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we get === Installation === === Running the container === == ROS package == === Create a new package === === Create a publisher === === Verify the publisher works === Use <code>rostopic echo /nautilus/text</code> = Add a Component to the Interface = In this section, we'll create the components to read in the data of our publisher. By the end of this section, you'll be able to create a ROS subscriber and add components to our interface. === Create a subscriber === === Send messages to the interface === === Create an interface component === And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! 43abc3e9b620de654a75c3ec04de4753a9bb268b 78 77 2021-09-19T15:20:23Z Bennedict Soesanto 8 started adding content to setting up docker section wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of units called containers. Here's a useful video to get you started on docker: https://youtu.be/iqqDU2crIEQ. === Installation === === Running the container === == ROS package == === Create a new package === === Create a publisher === === Verify the publisher works === Use <code>rostopic echo /nautilus/text</code> = Add a Component to the Interface = In this section, we'll create the components to read in the data of our publisher. By the end of this section, you'll be able to create a ROS subscriber and add components to our interface. === Create a subscriber === === Send messages to the interface === === Create an interface component === And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! 77c34818dd81160f9e75adc25cf21ce33d914655 79 78 2021-09-19T15:33:17Z Bennedict Soesanto 8 added hyperlink wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. Docker can be viewed as a lightweight alternative to virtual machines suitable for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === === Running the container === == ROS package == === Create a new package === === Create a publisher === === Verify the publisher works === Use <code>rostopic echo /nautilus/text</code> = Add a Component to the Interface = In this section, we'll create the components to read in the data of our publisher. By the end of this section, you'll be able to create a ROS subscriber and add components to our interface. === Create a subscriber === === Send messages to the interface === === Create an interface component === And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! 427d165247ad6d2190f0454f1296957269d4a4db 80 79 2021-09-19T16:05:23Z Bennedict Soesanto 8 added installation instructions wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === === Verify the publisher works === Use <code>rostopic echo /nautilus/text</code> = Add a Component to the Interface = In this section, we'll create the components to read in the data of our publisher. By the end of this section, you'll be able to create a ROS subscriber and add components to our interface. === Create a subscriber === === Send messages to the interface === === Create an interface component === And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! 7144f28ddc2185757617bed804d043bcc648cae3 90 80 2021-09-21T21:11:48Z Gunarp 7 start server section wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === === Verify the publisher works === Use <code>rostopic echo /nautilus/text</code> = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over making a ROS subscriber to read in that data and display the output on a terminal. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package. Let's create a new file <code>uwrov_server/src/servers/text_server.py</code> <syntaxhighlight lang="python" line> from .server_types import SubServer class TextServer(SubServer): def __init__(self, topic): self.sub = rospy.Subscriber(topic, String, self.callback, queue_size=1) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextServer</code> which extends the <code>SubServer</code> [https://github.com abstract class]. The <code>TextServer</code> class will create a subscriber, and publish any data it gets to the ROS log. Next let's register this subscriber to our main server in <code>uwrov_server/scripts/main_server.py</code> === Send messages to the interface === === Create an interface component === And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! 2746597f09f9de47a65f6b56cff83141c7e41d19 91 90 2021-09-21T21:16:25Z Gunarp 7 move subscriber from next section into this one wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over making a ROS subscriber to read in that data and display the output on a terminal. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package. Let's create a new file <code>uwrov_server/src/servers/text_server.py</code> <syntaxhighlight lang="python" line> from .server_types import SubServer class TextServer(SubServer): def __init__(self, topic): self.sub = rospy.Subscriber(topic, String, self.callback, queue_size=1) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextServer</code> which extends the <code>SubServer</code> [https://github.com abstract class]. The <code>TextServer</code> class will create a subscriber, and publish any data it gets to the ROS log. Next let's register this subscriber to our main server in <code>uwrov_server/scripts/main_server.py</code> === Send messages to the interface === === Create an interface component === And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! f3bb0aea7aa6f9ddbb0e6d7bfde53e1bb0f750e7 94 91 2021-09-22T00:21:02Z Gunarp 7 add server tutorial wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package. Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. The <code>TextSub</code> class creates a subscriber, and publishes received data to the ROS log. Now that we've defined how we want this Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>), and what label it should give that data (<code>sio_id</code>). <syntaxhighlight lang="python" highlight="3,15-19" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic, sio_route, sio_id): super().__init__(topic, String) self.sio_route = sio_route self.sio_id = sio_id self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data, 'id': self.id } self.sio.emit(self.sio, packet, broadcast=True) </syntaxhighlight> Next, let's add a few lines to <code>main_server.py</code> to reflect this change when we create our <code>TextSub</code> object. <syntaxhighlight lang="python" highlight="6,16-17"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', 'text_msg', None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route) # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! 1adb7662df6cb56af8b927060bb3c64ba262176c 95 94 2021-09-22T00:32:33Z Gunarp 7 add directory visualizations wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. The <code>TextSub</code> class creates a subscriber, and publishes received data to the ROS log. Now that we've defined how we want this Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>), and what label it should give that data (<code>sio_id</code>). <syntaxhighlight lang="python" highlight="3,15-19" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic, sio_route, sio_id): super().__init__(topic, String) self.sio_route = sio_route self.sio_id = sio_id self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data, 'id': self.id } self.sio.emit(self.sio, packet, broadcast=True) </syntaxhighlight> Next, let's add a few lines to <code>main_server.py</code> to reflect this change when we create our <code>TextSub</code> object. <syntaxhighlight lang="python" highlight="6,16-17"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', 'text_msg', None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route) # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll be making a few files: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ │ │ ├─ text/ │ │ │ ├─ *text.css │ │ │ ├─ *text.js </pre> And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! 318d7bb7ab88a55e55696bb96ec932c8897e563e 96 95 2021-09-22T00:45:51Z Gunarp 7 /* Send messages to the interface */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. The <code>TextSub</code> class creates a subscriber, and publishes received data to the ROS log. Now that we've defined how we want this Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>), and what label it should give that data (<code>sio_id</code>). <syntaxhighlight lang="python" highlight="3,15-19" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic, sio_route, sio_id): super().__init__(topic, String) self.sio_route = sio_route self.sio_id = sio_id self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data, 'id': self.id } self.sio.emit(self.sio, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-17"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', 'text_msg', None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route) # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll be making a few files: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ │ │ ├─ text/ │ │ │ ├─ *text.css │ │ │ ├─ *text.js </pre> And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! 5b4c0569140c3e47cb05194a02612c2d56399fd8 97 96 2021-09-22T03:56:38Z Gunarp 7 remove sio_id tag wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. The <code>TextSub</code> class creates a subscriber, and publishes received data to the ROS log. Now that we've defined how we want this Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic) # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll be making a few files: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ │ │ ├─ text/ │ │ │ ├─ *text.css │ │ │ ├─ *text.js </pre> And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! b1eb9578639a15fd0c9a031fd42a5506927c2a8a 98 97 2021-09-22T04:28:12Z Gunarp 7 /* Send messages to the interface */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. The <code>TextSub</code> class creates a subscriber, and publishes received data to the ROS log. Now that we've defined how we want this Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route) # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll be making a few files: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ │ │ ├─ text/ │ │ │ ├─ *text.css │ │ │ ├─ *text.js </pre> And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! e8e0a443f6ffed9fff8c2d3c36b396f46c79f206 99 98 2021-09-22T05:22:39Z Gunarp 7 /* Add a subscriber to the server */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. The <code>TextSub</code> class creates a subscriber, and publishes received data to the ROS log. Now that we've defined how we want this Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route) # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll be making a few files: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ │ │ ├─ text/ │ │ │ ├─ *text.css │ │ │ ├─ *text.js </pre> And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! 2c61127c87d867f2af870b91eed3cb08cb70ebd4 100 99 2021-09-22T05:23:12Z Gunarp 7 /* Add a subscriber to the server */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. The <code>TextSub</code> class creates a subscriber, and publishes received data to the ROS log. Now that we've defined how we want this Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route) # Register our subscribers and publishers for handle in subscribers: subinfo = subscribers[handle] subinfo.sub = ImageSub(subinfo.ros_topic, subinfo.sio_route) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll be making a few files: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ │ │ ├─ text/ │ │ │ ├─ *text.css │ │ │ ├─ *text.js </pre> And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! cc4cf7ecb5e016838bf6e6f88b9a0654c6aadcab 0 16 81 2021-09-21T02:48:08Z Gunarp 7 initial wikitext text/x-wiki === Get all your organizational stuff set up === # [https://discord.gg/aQjnFs9NP9 Discord] # [https://uwrov.monday.com/users/sign_up?invitationId=15124477945852756000 monday.com] # Google Drive # GitHub === Get your development environment set up === # Download VSCode # Download Docker # Complete our [[Software/Starting Tutorial | development tutorial]] 8188526ed8f193dfc787415ea6f3fbfdd8c26cd5 0 15 101 100 2021-09-22T05:24:20Z Gunarp 7 /* Send messages to the interface */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. The <code>TextSub</code> class creates a subscriber, and publishes received data to the ROS log. Now that we've defined how we want this Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll be making a few files: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ │ │ ├─ text/ │ │ │ ├─ *text.css │ │ │ ├─ *text.js </pre> And now you're finished! You successfully created a ROS package which sends data from a terminal to the interface, and an interface component to display that data! This was a lot of work, so luckily you won't be alone! ddf281b6a7d762860cd058ee75a59af081188beb 102 101 2021-09-22T05:44:47Z Gunarp 7 first draft of second section wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. The <code>TextSub</code> class creates a subscriber, and publishes received data to the ROS log. Now that we've defined how we want this Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 3a6a5e25c84e8b6965b610dde073ea904e433a96 103 102 2021-09-22T05:52:01Z Gunarp 7 /* Add a subscriber to the server */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto the interface. In this tutorial we'll create a ROS package which will display items you type into your terminal on a window in our interface! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to the Interface = In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! b06051e4d2caaeff0b8b5df48b69a45faaf25abb 104 103 2021-09-22T05:53:34Z Gunarp 7 wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before we are able to create a ROS package, we will need to install and configure the necessary files, libraries and dependencies. To ensure a simple and consistent setup process, we will be making use of a tool called Docker. Briefly, Docker is an application build and deployment tool that makes use of deployable units called containers. They are a lightweight alternative to virtual machines, making the suitable to use for our ROV. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. === Installation === We are going to be using Docker Desktop for our development. To download this, click this [https://www.docker.com/products/docker-desktop link]. Simply download and install Docker Desktop and make sure to launch the program in the background while you have your code editor window up. === Running the container === == ROS package == === Create a new package === === Create a publisher === ==== Test the publisher ==== Run the publisher and use <code>rostopic echo /nautilus/text</code> in another terminal and check to see that any messages you enter into the publisher appear here. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! ef6beb5268b0a47084851b247b4fc4804f2a4274 109 104 2021-09-23T07:02:08Z Bennedict Soesanto 8 Rewording and finished publisher section wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which contains the instructions to build the Docker container image. To learn more, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of OpenCV python # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> File Definitions: ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> ## Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. ### Navigate backt o the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 86af1803a473499f86d2dbb98ce7398df0c2d017 110 109 2021-09-23T07:03:19Z Bennedict Soesanto 8 grammar fix wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of OpenCV python # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> File Definitions: ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> ## Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. ### Navigate backt o the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 13827d93631a4b54444e6bcbbe4a1af65a40678c 111 110 2021-09-23T07:03:46Z Bennedict Soesanto 8 /* Setting up Docker */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of OpenCV python # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> File Definitions: ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> ## Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. ### Navigate backt o the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! b13f4bd3b1d737829addb4c2ad6283dd2f2130fa 112 111 2021-09-23T07:04:00Z Bennedict Soesanto 8 /* Setting up Docker */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of OpenCV python # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> File Definitions: ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> ## Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. ### Navigate backt o the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 44d68f5a5e03d248b9a7b333a0dc7aa2cf34be03 113 112 2021-09-23T07:04:52Z Bennedict Soesanto 8 /* Running the container */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> File Definitions: ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> ## Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. ### Navigate backt o the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! da28df764f49d15c011cfd3aa815f7fbea1263a8 114 113 2021-09-23T07:05:29Z Bennedict Soesanto 8 /* Running the container */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for your reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> File Definitions: ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> ## Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. ### Navigate backt o the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 551df08f2e199f6657b0bd3b26eacdad60477087 115 114 2021-09-23T07:05:56Z Bennedict Soesanto 8 /* ROS package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for your reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> ## Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. ### Navigate backt o the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 55fe04b6e0865334806739763d82c93e4aa2be68 116 115 2021-09-23T07:06:14Z Bennedict Soesanto 8 /* Create a new package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for your reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package </pre> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> ## Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. ### Navigate backt o the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 535ce9cedbe7467b16f007b7cef90d51bf9aa83b 117 116 2021-09-23T07:06:32Z Bennedict Soesanto 8 /* Create a new package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for your reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> ## Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. ### Navigate backt o the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 55fe04b6e0865334806739763d82c93e4aa2be68 118 117 2021-09-23T07:07:09Z Bennedict Soesanto 8 /* Create a new package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for your reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. A typical ROS directory may look something like this: <pre> workspace src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;workspace : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> # Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 8178fb24c3819d9a12850b63dd6b06cd7e3bb524 119 118 2021-09-23T07:08:27Z Bennedict Soesanto 8 /* ROS package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for your reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Our ROS directory's structure looks something like this: <pre> nautilus_surface src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;nautilus_surface : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/workspace_folder/src</code> # Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! b63dba18f3ce54165734b8e39af73de6fc205875 120 119 2021-09-23T07:09:09Z Bennedict Soesanto 8 /* ROS package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for your reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Our ROS directory's structure looks something like this: <pre> nautilus_surface src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;nautilus_surface : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 2e056b5678812d490a30f60181f43d8ebe447f89 121 120 2021-09-23T07:11:50Z Bennedict Soesanto 8 /* Create a publisher */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for your reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Our ROS directory's structure looks something like this: <pre> nautilus_surface src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;nautilus_surface : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make again, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! cb3c154487e2a9af4727a2c802b3a9f4beb21765 122 121 2021-09-23T07:12:10Z Bennedict Soesanto 8 /* Test the publisher */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Running the container === Launch Docker Desktop on a separate window to your preferred code editor to oversee the running process. But before we can actually run our container, we need to build an image based on the Dockerfile with these [https://kapeli.com/cheat_sheets/Dockerfile.docset/Contents/Resources/Documents/index instructions]. Here's the [https://github.com/uwrov/nautilus_surface/blob/main/Dockerfile sample] Dockerfile for our tutorial. Notes: # FROM instructs docker to build on top of ROS Noetic # COPY takes the first argument as the source and copies to the second argument which is the destination # WORKDIR sets the current working directory # ENV creates constant variables for later use # RUN installs different libraries and dependencies for our image After configuring the Dockerfile, head to your terminal to build the image and run it. Note that the initial build process will take some time. Next, open up a bash interface in the terminal, and you're all set up!. Here's a [https://github.com/uwrov/nautilus_surface/blob/main/docker.md read me] for your reference. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Our ROS directory's structure looks something like this: <pre> nautilus_surface src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;nautilus_surface : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 0edc56cfacdb5c76d636b3893bd7d32bfcfe837c 124 122 2021-09-23T16:13:40Z Gunarp 7 /* Setting up Docker */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </sytnaxhighlight> This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|frame|left|Docker Desktop UI after running <code>docker compose up</code>]] == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Our ROS directory's structure looks something like this: <pre> nautilus_surface src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;nautilus_surface : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 446755cd49686e45c27eb8f099cbbde50a76a910 125 124 2021-09-23T16:19:03Z Gunarp 7 fix image format wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Our ROS directory's structure looks something like this: <pre> nautilus_surface src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;nautilus_surface : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 7dec25e07d45cc669ce17d7afe099a7f8922927a 127 125 2021-09-23T16:23:22Z Gunarp 7 add build instructions wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Our ROS directory's structure looks something like this: <pre> nautilus_surface src CMakeLists.txt {package} CMakeLists.txt package.xml </pre> ;nautilus_surface : name of workspace ;src : source space that contains ROS packages ;CMakeLists.txt : text file that stores directives and instructions that define the source files and targets for the project ;{package} : name of package ;package.xml : defines properties of the package To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg {package} std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this] page from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 613f7f610592df99d5a7b56526d8cf57534d0a3b 128 127 2021-09-23T16:38:42Z Gunarp 7 /* Create a new package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>{package}/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) rate = rospy.Rate(1) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) rate.sleep() if __name__ == '__main__': main() </syntaxhighlight> The next step is to update our catkin make text file to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun catkin_make, as well as source if needed. Run the publisher using <code>rosrun {package} pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! c906536e05d10322f47d95a9d3ccdf21f723a5ab 129 128 2021-09-23T16:40:44Z Gunarp 7 /* Create a publisher */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Run the publisher using <code>rosrun nautilus_text pub.py</code> and use <code>rostopic echo /natulius/text</code> in another terminal to check if the topic has been published. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 53697c58fbbcfe4c5c5d4a68bf0f273fc23d2914 130 129 2021-09-23T16:45:46Z Gunarp 7 /* Test the publisher */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! a0d358b24948054c2ce72d4ff11ce3b52ab85e3e 132 130 2021-09-23T16:47:39Z Gunarp 7 /* Run the container */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>{package}/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> ==== Test the subscriber ==== Run the subscriber and use <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> in a separate terminal and verify that <code>heyo</code> prints in the subscriber's terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 7309a1ff72d455ca5e3ea9fc76e3afab90f2eda0 133 132 2021-09-23T16:51:09Z Gunarp 7 /* Create a subscriber */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): pub = rospy.Publisher('/nautilus/text', String, queue_size=10) rospy.init_node('text_publisher', log_level=rospy.DEBUG) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! d642d99c635acf8b0d5a983b0a749678d68aeabc 134 133 2021-09-23T16:51:52Z Gunarp 7 /* Create a publisher */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Run both the publish and subscriber and see that messages get passed around! = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 2ecebf632db3ae697e5a12bca36eff24172d0c22 135 134 2021-09-23T16:53:34Z Gunarp 7 /* Test the publisher and subscriber together */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! ea1164f5a72191b239b2e600fc9ed7a68c079ff6 136 135 2021-09-23T16:55:58Z Gunarp 7 /* Test the subscriber */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 15bf9904905b9aabd6599f48dce2908003488393 137 136 2021-09-23T17:39:02Z Gunarp 7 /* Create a subscriber */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun</code>. We should now be able to see the text on the interface update as we send messages in the terminal! == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! d13c015cdac35ec252bb9849034a38f708a38057 138 137 2021-09-23T17:44:20Z Gunarp 7 /* Testing */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 858fc96a6f9da69aff43c3227257e68b9b0946f8 139 138 2021-09-23T17:49:08Z Gunarp 7 /* Run the container */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Simply select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! da7fcd065255afe2496f4351745b34eee5998102 145 139 2021-09-24T20:44:33Z Gunarp 7 /* Installation */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git set up, then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> git clone git@github.com:uwrov/nautilus_surface.git # OR git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 68e6b5abfd1621033e7823fb9449f45ae46e914a 146 145 2021-09-24T20:45:19Z Gunarp 7 /* Clone the repo */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but just know that they're responsible for setting up the runtime environment. After docker finishes building the image, it will launch a container. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 8f793d9f36e0f708def6b8cae03f55e4061f954c 147 146 2021-09-24T21:11:09Z Gunarp 7 /* Run the container */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Docker == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 5b26210ea1b1781aed246a9bebfde7cd2e69d8eb 148 147 2021-09-24T22:33:46Z Gunarp 7 /* Setting up Docker */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/nautilus_surface/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 0eebdb073c7da73da35cf4ea34c7fc19fe4c38a2 149 148 2021-09-24T23:47:17Z Gunarp 7 /* Create a new package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msg rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! d728a5b6c2b1a37b79e2ea1fa3c88de5a7a79969 150 149 2021-09-25T00:06:13Z Gunarp 7 /* Create a new package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import SeverSub class TextSub(SeverSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! d6ed3e1e0affa417e97da17e68d14fcaf4f9a539 0 17 105 2021-09-22T14:19:22Z Ajang304 9 Created page with "Here we outline the architecture and high-level details for our software systems. For more detailed information on each system, head over to github for documentation. {{/onbo..." wikitext text/x-wiki Here we outline the architecture and high-level details for our software systems. For more detailed information on each system, head over to github for documentation. {{/onboard}} {{/interface}} 62c1c92d010e70bb4c7bac87c5322ac0b2981c2e 106 105 2021-09-22T14:20:56Z Ajang304 9 wikitext text/x-wiki Here we outline the architecture and high-level details for our software systems. For more detailed information on each system, head over to github for documentation. {{/Onboard Systems}} {{/Interface Architecture}} 61c9d91ccf8e6f8e3fcf4426c98adc3bebfc66c1 107 106 2021-09-22T23:18:43Z Gunarp 7 wikitext text/x-wiki Here we outline the architecture and high-level details for our software systems. For more detailed information on each system, head over to github for documentation. [[/ROS | ROS]] [[/OceanUI | OceanUI]] aa56acf8ebd15db8c023a3a0b5eaede3f447e82b 108 107 2021-09-22T23:19:08Z Gunarp 7 wikitext text/x-wiki Here we outline the architecture and high-level details for our software systems. For more detailed information on each system, head over to github for documentation. *[[/OceanUI | OceanUI]] *[[/ROS | ROS]] 5a35a80d7a6ad21df2146c28917b9bb19eda03c4 141 108 2021-09-23T17:51:26Z Ajang304 9 wikitext text/x-wiki Here we outline the architecture and high-level details for our software systems. For more detailed information on each system, head over to github for documentation. *[[System/Interface_Architecture | OceanUI]] *[[/ROS | ROS]] bccd32323e4917bacc4b8d5257f9b0901424dddf 142 141 2021-09-23T17:52:36Z Ajang304 9 wikitext text/x-wiki Here we outline the architecture and high-level details for our software systems. For more detailed information on each system, head over to github for documentation. *[[/Interface Architecture | OceanUI]] *[[/ROS | ROS]] bdd422a8c4b84701bd8a8c8727d209cdeb6e5a95 143 142 2021-09-23T17:52:55Z Ajang304 9 wikitext text/x-wiki Here we outline the architecture and high-level details for our software systems. For more detailed information on each system, head over to github for documentation. *[[/Interface Architecture | OceanUI]] *[[/ROS | ROS]] {{/Interface Architecture}} 8eb70cc9d457a0eb09b80d4132b3f78054e61775 6 18 123 2021-09-23T16:08:32Z Gunarp 7 Screenshot of docker desktop ui after running `docker compose up` wikitext text/x-wiki == Summary == Screenshot of docker desktop ui after running `docker compose up` 177415feb3a285b87614e808dc1b652168adca26 126 123 2021-09-23T16:19:29Z Gunarp 7 Gunarp uploaded a new version of [[File:Docker desktop compose.png]] wikitext text/x-wiki == Summary == Screenshot of docker desktop ui after running `docker compose up` 177415feb3a285b87614e808dc1b652168adca26 131 126 2021-09-23T16:46:30Z Gunarp 7 Gunarp uploaded a new version of [[File:Docker desktop compose.png]] wikitext text/x-wiki == Summary == Screenshot of docker desktop ui after running `docker compose up` 177415feb3a285b87614e808dc1b652168adca26 0 19 140 2021-09-23T17:49:57Z Ajang304 9 Created page with "Our main philosophy for OceanUI is modularity and flexibility. With the competition requiring multiple different functionalities each year, the interface should be able to hav..." wikitext text/x-wiki Our main philosophy for OceanUI is modularity and flexibility. With the competition requiring multiple different functionalities each year, the interface should be able to have features that can be changed and added easily. For this reason, we designed OceanUI as a blank canvas that can have components that can be added, removed and changed flexibly depending on the need for the current year. OceanUI is built off of the React.js library and its widgets are extended from the React.Components class. === Widgets === OceanUI's features revolve around components that we call Widgets. Each widget is a UI component that has specific functionalities such as camera feed, controller input, automation, and more. 3341019eaf54138c327a24812928fc204bbdf37c 144 140 2021-09-23T17:53:30Z Ajang304 9 wikitext text/x-wiki == OceanUI Architecture == Our main philosophy for OceanUI is modularity and flexibility. With the competition requiring multiple different functionalities each year, the interface should be able to have features that can be changed and added easily. For this reason, we designed OceanUI as a blank canvas that can have components that can be added, removed and changed flexibly depending on the need for the current year. OceanUI is built off of the React.js library and its widgets are extended from the React.Components class. === Widgets === OceanUI's features revolve around components that we call Widgets. Each widget is a UI component that has specific functionalities such as camera feed, controller input, automation, and more. a91e02f9eb511f76db3c16be98b3a02f556c74f4 0 15 151 150 2021-09-25T01:24:01Z Gunarp 7 /* Add a subscriber to the server */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route): super().__init__(topic, String) self.sio_route = sio_route self.sio = SocketIO() def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! f41d89b1ae8ff5235800e9416b2e8f7046a92004 152 151 2021-09-25T01:52:08Z Gunarp 7 /* Send messages to the interface */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate back to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 5f71cfcdff8970a0d6dd0db297a5a322929f17c7 154 152 2021-09-25T05:27:34Z Gunarp 7 /* Create a new package */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! f3933b6e5467402e37679048c9ff2fcdb8e67078 155 154 2021-09-25T05:27:48Z Gunarp 7 /* Test the publisher */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === Before we create our publisher and subscriber, it may be useful to read about nodes, messages and topics for ROS. Now that you have, let's create a sample publisher in <code>nautilus_text/scripts/pub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. Under catkin configurations, where you see the following block of code <pre> catkin_package( ... ) </pre> , add the following lines directly below it: <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> ==== Test the publisher ==== Navigate back to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 668c04776df8ce5cdc540888c3d970ab65aeb133 156 155 2021-09-25T05:37:42Z Gunarp 7 /* Create a publisher */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see text appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! a9e968a21ce0b82789359a603ef43f5df9b9cd02 157 156 2021-09-25T05:38:04Z Gunarp 7 /* Test the subscriber */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/test_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! e0224284a506fd4b4191a6f9bbe102c9c53f2208 158 157 2021-09-25T05:46:49Z Gunarp 7 /* Add a subscriber to the server */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! c9dd6da7689bba7fbc27fce80439d3c93eb21272 159 158 2021-09-25T05:52:42Z Gunarp 7 /* Send messages to the interface */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! ce307b4cebbdfb8fca0d3daba78ec968446b18ee 160 159 2021-09-25T05:54:05Z Gunarp 7 /* Send messages to the interface */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ GUI/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! cf0c3f38859994a435e6eaea7d3314f349b86bf6 161 160 2021-09-25T05:56:20Z Gunarp 7 /* Create an interface component */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from '../components/text/text.js' import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! df9d4e238dbb2226789ca4a7bcfd969604d33575 162 161 2021-09-25T06:02:47Z Gunarp 7 /* Register the component in the GUI */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from "../components/text/text.js"; import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript" highlight="4"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! d3096cce67039b4ac75624829d145f63423b145e 163 162 2021-09-25T06:05:01Z Gunarp 7 /* Register the component in the GUI */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from "../components/text/text.js"; import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>GUI.js</code> <syntaxhighlight lang="javascript" highlight="4"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000 http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! af9c6d78cddea4a7206d2a0090d4468177b0fa1e 164 163 2021-09-25T06:22:37Z Gunarp 7 /* Register the component in the GUI */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from "../components/text/text.js"; import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>gui.js</code> <syntaxhighlight lang="javascript" highlight="4"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000 http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text sub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 37e3ea95c009137d1901ce317e35a17403f769af 165 164 2021-09-25T06:22:54Z Gunarp 7 /* Testing */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from "../components/text/text.js"; import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>gui.js</code> <syntaxhighlight lang="javascript" highlight="4"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000 http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text pub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 2a65618c04aac3e76a9b433c5d20d3a483fdbb27 166 165 2021-09-25T06:33:30Z Gunarp 7 /* Setting up Dev Environment */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. === Getting familiar with UNIX === If this is your first time using a UNIX command line, now's a great time to take a pause and get a little more comfortable with command line control. Check out this [http://www.ee.surrey.ac.uk/Teaching/Unix/unix1.html lesson] on navigational UNIX commands, and try to explore our repo with just your keyboard! == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from "../components/text/text.js"; import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>gui.js</code> <syntaxhighlight lang="javascript" highlight="4"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000 http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text pub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 48bf5d31b2aece95efeafef54cf4c0da9645be11 167 166 2021-09-25T06:42:01Z Gunarp 7 /* Getting familiar with UNIX */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. === Getting familiar with UNIX === If this is your first time using a UNIX command line, now's a great time to take a pause and get a little more comfortable with command line control. Check out this [http://www.ee.surrey.ac.uk/Teaching/Unix/unix1.html lesson] on navigational UNIX commands, and try to explore our repo with just your keyboard! Most commands are like verbs of a sentence - they describe some sort of ''action'' that's being taken. Other arguments passed into a command serve as the nouns of our sentence, or what items are performing the commands. Typically, commands will come in the form of <code>_command_ _file or directory_</code>. == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from "../components/text/text.js"; import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>gui.js</code> <syntaxhighlight lang="javascript" highlight="4"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000 http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text pub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! b242e72d7d80a19f80c2896a9774e8617885ca0e 168 167 2021-09-25T06:42:57Z Gunarp 7 /* Getting familiar with UNIX */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. === Getting familiar with UNIX === If this is your first time using a UNIX command line, now's a great time to take a pause and get a little more comfortable with command line control. Check out this [http://www.ee.surrey.ac.uk/Teaching/Unix/unix1.html lesson] on navigational UNIX commands, and try to explore our repo with just your keyboard! Most commands are like verbs of a sentence - they describe some sort of ''action'' that's being taken. Other arguments passed into a command serve as the nouns of our sentence, or what items are performing the commands.<br> Typically, commands will come in the form of <code>_command_ _file/dir_</code>. If you're ever curious about what specific command does, you can find out more about it by running </code>man _command_</code> == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from "../components/text/text.js"; import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>gui.js</code> <syntaxhighlight lang="javascript" highlight="4"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000 http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text pub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 32e18c13f2116500762c47e9a874ec9120480dd9 169 168 2021-09-25T21:41:05Z Gunarp 7 add link to video playlist wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! If you'd like we also have a video playlist going through this tutorial here: https://www.youtube.com/playlist?list=PLg_KrxeCCucuS0NynCLM10LIpMwv9yl3y = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. === Getting familiar with UNIX === If this is your first time using a UNIX command line, now's a great time to take a pause and get a little more comfortable with command line control. Check out this [http://www.ee.surrey.ac.uk/Teaching/Unix/unix1.html lesson] on navigational UNIX commands, and try to explore our repo with just your keyboard! Most commands are like verbs of a sentence - they describe some sort of ''action'' that's being taken. Other arguments passed into a command serve as the nouns of our sentence, or what items are performing the commands.<br> Typically, commands will come in the form of <code>_command_ _file/dir_</code>. If you're ever curious about what specific command does, you can find out more about it by running </code>man _command_</code> == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from "../components/text/text.js"; import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>gui.js</code> <syntaxhighlight lang="javascript" highlight="4"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000 http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text pub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! f044acaf97d0a275dbb4d3679ada7900c33cb5e6 172 169 2021-10-21T03:24:35Z Gunarp 7 /* Run the container */ wikitext text/x-wiki Here's a step by step tutorial which will show you how to create your first ROS package, and add a component onto our interface - OceanUI. In this tutorial we'll create a ROS package which will display items you type into your terminal on an OceanUI widget! If you'd like we also have a video playlist going through this tutorial here: https://www.youtube.com/playlist?list=PLg_KrxeCCucuS0NynCLM10LIpMwv9yl3y = Creating your first ROS package = In this section, we'll set up docker and create a ROS package. By the end of this section, you'll be able to launch our control system and create a ROS publisher. == Setting up Dev Environment == Before creating our first ROS package, we need to install the necessary dependencies for our environment. To help us with setup, we will be making use of Docker, which is a lightweight alternative to virtual machines. Briefly, Docker is a container based application build and deployment tool. Each docker container starts with a simple text file called the Dockerfile which has the instructions to build the Docker container image. To learn more about Docker, click [https://www.ibm.com/cloud/learn/docker here]. This optional [https://docs.docker.com/get-started/ video] showcases everything covered within the Docker setup subsection. === Installation === For our development purposes, we will be using [https://www.docker.com/products/docker-desktop Docker Desktop]. Select and install the suitable Docker Desktop software for your operating system. === Clone the repo === Now let's get our development environment all set. Make sure you have git [https://docs.github.com/en/get-started/quickstart/set-up-git set up], then find a place where you'd like to be working from and clone the repo with: <syntaxhighlight lang="bash"> # With SSH (preferred) git clone git@github.com:uwrov/nautilus_surface.git # OR # With https git clone https://github.com/uwrov/nautilus_surface.git </syntaxhighlight> This will download a copy of our source code and configuration files onto your computer. === Run the container === Now, open a terminal in the freshly cloned repo folder and run <syntaxhighlight lang="bash"> docker compose up </syntaxhighlight > This will take a few minutes to set up and run an image based on the configuration from <code>Dockerfile</code> and <code>docker-compose.yaml</code> - we won't go into the contents of those files in this tutorial, but here are some items which might be helpful to know when running our container: * <code>Dockerfile</code> contains instructions on how to build a docker image, while <code>docker-compose.yaml</code> contains instructions on how to run the image. * When you run with <code>docker compose up</code>, your local source code files will be connected to your container's filesystem, so editing the contents of the <code>src</code> directory will cause changes in the container's copy of those files, and vice versa. After docker finishes building the image, it will display the message <code>attaching to surface</code>. This terminal will appear to hang, so you can either open a new terminal and run some commands to ssh into the container, or open terminals on the container through Docker Desktop. If you have Docker Desktop, you should be able to see the container is running in the <code>Containers/Apps</code> section. [[File:docker_desktop_compose.png|border|Docker Desktop UI after running <code>docker compose up</code>]] You can launch new terminals in the container by pressing the <code>CLI</code> button. Note that this button launches a default <code>sh</code> terminal, but we typically want to be working in a <code>bash</code> terminal. To get around this make sure to run <code>bash</code> in each new terminal you create. There's currently no way to change this behavior. === Getting familiar with UNIX === If this is your first time using a UNIX command line, now's a great time to take a pause and get a little more comfortable with command line control. Check out this [http://www.ee.surrey.ac.uk/Teaching/Unix/unix1.html lesson] on navigational UNIX commands, and try to explore our repo with just your keyboard! Most commands are like verbs of a sentence - they describe some sort of ''action'' that's being taken. Other arguments passed into a command serve as the nouns of our sentence, or what items are performing the commands.<br> Typically, commands will come in the form of <code>_command_ _file/dir_</code>. If you're ever curious about what specific command does, you can find out more about it by running </code>man _command_</code> == ROS package == === Create a new package === Now that we have our environment set up using Docker, and prepared a bash interface, we are ready to create our first ROS package. Let's examine how our ROS packages are organized within our container: <pre> catkin_ws/ -- Workspace folder ├─ src/ ├─ CMakeLists.txt -- Top level CMake, autogenerated │ ├─ nautilus_launch/ │ │ ├─ scripts/ │ │ ├─ CMakeLists.txt -- Describes how to build this package │ │ ├─ package.xml -- Package manifest │ ├─ {other packages}/ </pre> Now, let's go ahead and create a brand new package called <code>nautilus_text</code> To create a new package, follow these steps: # Navigate your way into the src directory using <code>cd ~/catkin_ws/src</code> # Use <code>catkin_create_pkg nautilus_text std_msgs rospy roscpp</code>. Here, std_msg, rospy and roscpp are all dependencies for our new package. It is also possible to add dependencies to an existing ROS package by editing the <code>package.xml</code> file. # Navigate up to the workspace directory and run <code>catkin_make</code> in your interface to build the catkin workspace. If your run into any issues running this, do <code>source devel/setup.bash</code>. Take a look at [http://wiki.ros.org/ROS/Tutorials/CreatingPackage this page] from the ROS Wiki for more detailed documentation. === Create a publisher === For some context, the simplest method of communication offered by ROS is the pub/sub system. Where nodes can create publishers, which publish data to topics. Nodes can also create subscribers, which consume data published to a topic. You can read more about topics [http://wiki.ros.org/Topics here]. Now that you have a rough idea of what a publisher and subscriber do, let's jump into code by crating a brand new publisher: <code>nautilus_text/scripts/pub.py</code>. Create that file within the <code>src</code> directory on your local copy of the repo, changes are automatically synced to your container's filesystem when you launch the container with <code>docker compose up</code>. If you'd like, you can also edit files directly in the terminal by downloading your favorite text editor (such as vim), do note that you'll have to do this every time you build the image from scratch, though. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def main(): rospy.init_node('text_publisher', log_level=rospy.DEBUG) pub = rospy.Publisher('/nautilus/text', String, queue_size=10) while not rospy.is_shutdown(): msg = input("Enter message: ") pub.publish(msg) if __name__ == '__main__': main() </syntaxhighlight> The next step is to update <code>nautilus_text/CMakeLists.txt</code> to ensure that the publisher is properly defined. You can go straight to the bottom of the file and add <pre> catkin_install_python(PROGRAMS scripts/pub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </pre> This will tell catkin to include <code>pub.py</code> in the build process, and allow us to run the script using </code>rosrun nautilus_text pub.py</code> ==== Test the publisher ==== Navigate up to the workspace directory and rerun <code>catkin_make</code>, as well as source if needed. Then, open 3 bash terminals and do the following: # Run <code>roscore</code>, this initializes the ROS master node # Run <code>rosrun nautilus_text pub.py</code> # Run <code>rostopic echo /nautilus/text</code> Now, type text into the window running <code>nautilus_text pub.py</code> and verify that messages show up in the terminal you ran <code>rostopic echo</code> in. === Create a subscriber === Let's create a sample subscriber in <code>nautilus_text/scripts/sub.py</code>. <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String def callback(msg): rospy.loginfo(msg.data) def main(): rospy.init_node('text_server', log_level=rospy.DEBUG) rospy.Subscriber('/nautilus/text', String, callback) rospy.spin() if __name__ == '__main__': main() </syntaxhighlight> Now, let's register our subscriber in <code>nautilus_text/CMakeLists.txt</code> by adding the following to the bottom of the file. <syntaxhighlight> catkin_install_python(PROGRAMS scripts/sub.py DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} ) </syntaxhighlight> Finally, let's ensure our subscriber has been registered with ROS by running the following in the <code>catkin_ws</code> directory. <syntaxhighlight> catkin_make </syntaxhighlight> ==== Test the subscriber ==== Similar to what we did to test the publisher, let's open 3 terminals and do the following: # Run <code>roscore</code> # Run <code>rosrun nautilus_text sub.py</code> # Run <code>rostopic pub /nautilus/text std_msgs/String "data: 'heyo'"</code> After running the <code>rostopic</code> command, you should see "heyo" appear in the subscriber terminal. === Test the publisher and subscriber together === Now, let's run both the publisher and subscriber and check to make sure that messages can get passed around! Open 3 terminals - one for each of the following: # <code>roscore</code> # <code>rosrun nautilus_text pub.py</code> # <code>rosrun nautilus_text sub.py</code> = Add a Component to OceanUI= In this section, we'll create the components to display the data from our publisher on our interface. By the end of this section you'll be able to create a ROS subscriber and add a component to our interface. === Add a subscriber to the server === In this section we'll go over adding a ROS subscriber to our server. <br/> So far we have a publisher which pushes <code>String</code> messages to <code>/nautilus/text</code>. We want to take the data pushed to the ROS topic and serve it on our interface, so we'll add a subscriber to the <code>uwrov_server</code> package, which is organized like so: <pre> uwrov_server/ ├─ scripts/ │ ├─ main_server.py (runs and maintains a socketio server) ├─ src/ │ ├─ publishers/ │ │ ├─ publisher.py (base class) │ ├─ subscribers/ │ │ ├─ subscriber.py (base class) │ │ ├─ *text_sub.py </pre> Let's create a new file <code>uwrov_server/src/subscribers/text_sub.py</code> <syntaxhighlight lang="python" line> import rospy from std_msgs.msg import String from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic): super().__init__(topic, String) def callback(self, msg): rospy.loginfo(msg.data) </syntaxhighlight> This will create a new class <code>TextSub</code> which extends the <code>ServerSub</code> [https://github.com/uwrov/nautilus_surface/blob/main/src/uwrov_server/src/subscribers/subscriber.py abstract class]. Children of the <code>ServerSub</code> abstract class hold both a ROS subscriber and a callback function. There is no difference in functionality between these subscribers and the ones from the previous section. The only reason the <code>ServerSub</code> class exists is to simplify the code in <code>main_server.py</code>. Next let's register this subscriber to our main server's ROS node in <code>uwrov_server/scripts/main_server.py</code> <syntaxhighlight lang="python" highlight="3,12"> ... from subscribers.image_sub import ImageSub from subscribers.text_sub import TextSub ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) text = TextSub('/nautilus/text') # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> <code>main_server.py</code> maintains a ROS node, so when we declare a new <code>TextSub</code> object, we also add a subscriber onto the server's ROS node. We can verify this by running <code>rosnode info surface</code> when running the server. ==== Test our subscriber ==== Take a minute to verify this subscriber is capable of receiving messages. Run <code>main_server.py</code> with <code>rosrun uwrov_server main_server.py</code>, and launch the publisher you made earlier in a separate terminal. You should see that the server prints your messages directly to console. === Send messages to the interface === So far we've created a ROS subscriber and verified that our server is capable of receiving the messages on <code>/nautilus/text</code>. Next let's connect our subscriber to socketio and start sending messages to the interface. In <code>text_sub.py</code>, we add in some socketio information to tell the subscriber where it should forward data to (<code>sio_route</code>). <syntaxhighlight lang="python" highlight="3,8,10-11,14-17" line> import rospy from std_msgs.msg import String from flask_socketio import SocketIO from .subscriber import ServerSub class TextSub(ServerSub): def __init__(self, topic, sio_route, sio): super().__init__(topic, String) self.sio_route = sio_route self.sio = sio def callback(self, msg): packet = { 'text': msg.data } self.sio.emit(self.sio_route, packet, broadcast=True) </syntaxhighlight> Next, let's manage our subscriber using a <code>SubInfo</code> object back in <code>main_server.py</code>. This is a more robust handle than what we had before, and also contains the same fields we just added to the subscriber. <syntaxhighlight lang="python" highlight="6,16-18"> ... # aux storage to make sure subscriber objects aren't garbage collected subscribers = { 'camera_h': SubInfo('/nautilus/cameras/stream', 'Image Display', 'camera_stream', None), 'img_h': SubInfo('/image/distribute', 'Image Display', 'img_sub', None), 'text_h': SubInfo('/nautilus/text', 'Text', None, None) } ... if __name__ == '__main__': """ Sets up rospy and starts servers """ rospy.loginfo("main server is running") rospy.init_node('surface', log_level=rospy.DEBUG) subscribers['text_h'].sub = TextSub(subscribers['text_h'].ros_topic, subscribers['text_h'].sio_route, sio) # Register our subscribers and publishers for handle in ['camera_h', 'img_h']: subinfo = subscribers[handle] subinfo.sub = ImageSub( subinfo.ros_topic, subinfo.sio_route, subinfo.sio_id, sio) publishers['channel_h'].pub = ChannelPub(publishers['channel_h'].ros_topic) publishers['move_h'].pub = MovePub(publishers['move_h'].ros_topic) ... </syntaxhighlight> === Create an interface component === Now that our subscribers are forwarding data through a socketio route, we can create an interface component to receive and render our text messages. To do this, we'll need to create a new component in the <code>uwrov_interface</code> package. Let's make a new component <code>text</code> in the <code>uwrov_interface/src/components</code> directory. We'll just be making one file: <pre> uwrov_interface/ ├─ src/ │ ├─ components/ | | ├─ gui/ | | | ├─ GUI.js │ │ ├─ text/ │ │ │ ├─ *text.js | ├─ datastructs/ | | ├─ WidgetLib.js </pre> ==== Create the component ==== Let's define our new component in <code>text.js</code> <syntaxhighlight lang="javascript" line> import React from "react"; export default class Text extends React.Component { constructor(props) { super(props); this.socket = require('socket.io-client')('http://localhost:4040') this.state = { text: "Placeholder text" }; this.socket.on("Text", this.updateText); } updateText = (data) => { console.log("got text update: " + data.text); this.setState({ text: data.text }); } render() { return ( <div className="text-box"> <p className="text">{this.state.text}</p> </div> ); } } </syntaxhighlight> This code defines a React component which connects to our server via socketio, and updates a text field by listening to the output of the "Text" socketio route. ==== Register the component in the GUI ==== Now that we have our component, we need to register it within our GUI. For that, let's start in <code>WidgetLib.js</code> <syntaxhighlight lang="javascript" highlight="4,8-9"> import React from "react"; import Console from "../components/console/Console.js"; import Text from "../components/text/text.js"; import Settings from "../components/settings/Settings.js"; ... switch (data.type) { case "text": return <Text props={data.savedProps} />; case "settings": return <Settings props={data.savedProps} />; ... </syntaxhighlight> Here, we've registered our <code>Text</code> as a component which can be put into a <code>Widget</code>, which is a containing component for all the items on our interface. Now let's make some final changes to <code>gui.js</code> <syntaxhighlight lang="javascript" highlight="4"> ... consoleShow: false, widgets: [new Widget("ros_camera"), new Widget("controller"), new Widget("script_runner"), new Widget("text")] }; ... </syntaxhighlight> This change will add an instance of our <code>Text</code> component as a default widget on the GUI - so when we start the interface a <code>Text</code> widget will already be there. Let's build the interface by running the following command in the <code>uwrov_interface</code> directory (you can get there by doing <code>roscd uwrov_interface</code>) <syntaxhighlight lang="bash"> npm ci </syntaxhighlight> It will take a minute to build, and then we can run <syntaxhighlight lang="bash"> npm start </syntaxhighlight> This will start the interface, which we can view by going to [http://localhost:3000 http://localhost:3000] on your favorite web browser (chrome works best). ==== Testing ==== Let's go and launch the system using <code>roslaunch nautilus_launch system.launch</code>. This will launch both the interface and server. Now let's open up a second terminal, and run our publisher with <code>rosrun nautilus_text pub.py</code>. We should now be able to see the text on the interface update as we send messages in the terminal! There might be a latency of up to 5 seconds between sending the message in the terminal and seeing the change on the interface. == End == Great job on finishing the tutorial! We covered a lot: * Creating a ROS Package * Creating a ROS publisher and subscriber * Creating a subscriber to interface with OceanUI * Creating and displaying a component on OceanUI There was a lot of material in this tutorial, so please feel free to come back to it as many times as you need to! 7c86bd7e0f0381d7427f76c591f2916b300f00dd 0 13 153 84 2021-09-25T03:43:52Z Ajang304 9 wikitext text/x-wiki * [[/Development Process | Development Process]] * [[/I need help | I need help]] * [[/Git | Working with Git]] a70f73ad80613fe189093234156e45f8b8f14a73 0 20 170 2021-09-25T21:42:57Z Ajang304 9 Created page with "The UWROV club will have sprint based work cycles to manage our development process. == Meeting Types == ==== Sprint Planning meeting - Team wide meeting - 2 weeks - 2 months..." wikitext text/x-wiki The UWROV club will have sprint based work cycles to manage our development process. == Meeting Types == ==== Sprint Planning meeting - Team wide meeting - 2 weeks - 2 months ==== * Decide on the time frame of the sprint; Plan reflection meeting date. * Each subteam will decide on a task to focus on for the sprint. ** Tasks should be reasonable to complete by the end of the sprint but not small that a lot of extra time will be left. * Make sure everyone has been assigned to a subteam and task. ==== Reflection meeting - Team wide meeting - End of sprint - Friday night for game night! ==== * Did you finish what you were assigned? ** Discuss what went well, what can be improved, any roadblocks? * Demos for applicable tasks; show us what you did! ** Last minute quick confirmation for deployable code. ** Pull to main branch if everything looks good ** Here is where our changes will be merged * Any change in priorities for the next sprint? ** A very basic, keep in mind for next sprint planning topics. * After the meeting, have a game night! ==== Check-in meeting - weekly - during subteam work time ==== * One person from each subteam comes to meeting to discuss progress with officers * Cross team code review ** Can everyone understand what others did? * Questions that should be answered: ** How is everything going / are you on track? ** Do you have a clear idea of what to do? ** What does the timeframe look like for progress? ** Is there anything you need from officers? ==== Subteam meeting - subteam meeting - daily ==== * A short meeting between subteams to get together for daily progress check ** What to get done for the day? ** Any roadblocks that we had that should be discussed? ** Require assistance from other teams? * Code review between subteam members ** Does everyone understand what is happening? * Prequel to work time. == Sprint Calendar == # Sprint Planning Meeting #* Plan out calendar and tasks for this coming sprint # Subteam Meeting #* First subteam meeting, go over tasks with an officer to get setup if required. # Each week have a check-in meeting #* One person from each team to check-in with officers. # Reflection Meeting #* I Go over everything and then merge to main branch e5393ac7f9bb8b55e3ece396cc32ec2d8f96d0aa 0 16 171 81 2021-09-28T05:00:50Z Gunarp 7 /* Get all your organizational stuff set up */ wikitext text/x-wiki === Get all your organizational stuff set up === # [https://discord.gg/aQjnFs9NP9 Discord] # [https://uwrov.monday.com/users/sign_up?invitationId=15124477945852756000 monday.com] # Google Drive # GitHub # Get to know your teammates! === Get your development environment set up === # Download VSCode # Download Docker # Complete our [[Software/Starting Tutorial | development tutorial]] 2f010338d2e144c26dc827f92bb460bef3b6e7ef 0 1 173 3 2021-10-22T16:49:52Z Alnis S 6 /* Welcome to {{SITENAME}}! */ wikitext text/x-wiki __NOTOC__ == Welcome to {{SITENAME}}! == Welcome to the UWROV wiki! Check out our subteam wiki areas: * [[Software]] * [[Mechanical]] === Contributing to the Wiki === * <span class="plainlinks">[[mw:Special:MyLanguage/Help:Contents|MediaWiki guide (e.g. navigation, editing, deleting pages, blocking users)]] * [[meta:FAQ|Miraheze FAQ]] * [[meta:Request features|Request settings changes on your wiki. (Extensions and Logo/Favicon changes should be done through Special:ManageWiki on your wiki]]. 364b732c33b3aa1a6327e134614447ea61a9393a 0 21 174 2021-10-22T17:17:07Z Alnis S 6 Created page with "Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. == Summary == === What does UWROV's mechanical..." wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === Our CAD model for our 2021 ROV Slightly out of date webpage about it Photo album from summer 2021 worlds There are three core areas of work for the HSL mechanical team: * Design - creating plans for everything physical on the sROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the satellite * Documentation & Operations - communicating the design to others and supporting the software & electrical team when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools does the team use? === CAD: Onshape Project management: Trello Documentation: Mediawiki === Why are we building a satellite? === Our long-term mission (~2030) is to build a scientifically useful CubeSat that orbits the moon, probably with ground-penetrating radar to map underground lava tube caves. In the nearer term (~2024), we will launch a pathfinder and technology demonstrator in preparation for the moon mission. Going to the moon is difficult and expensive, so we need to prove our design's feasibility and robustness ahead of time. === What are some key terms to know? === * CubeSat - low-cost miniature satellite form factor * HSL - Husky Satellite Lab * U - CubeSat size unit (10 cm cube), a measure of space (e.g. 6U CubeSat = 20x30x10 cm satellite) * AACT - Astronautics & Aeronautics department's [https://aact.space/ CubeSat team] * HS1 - HuskySat-1, the HSL's first CubeSat (it went to space!) * APL - UW's Advanced Propulsion Lab (not to be confused with the UW's Applied Physics Laboratory) === Where do we work? === The "Satellite Cave" is our primary in-person work area. You'll find it in the AERB basement, room 13. Across the hall, there's a hypersonic cannon, and there's a tokamak out in the hallway next to the elevator. Pretty cool! It's a shared space with AACT and a half dozen PhD projects, so please be careful with all of the equipment and stuff in there. Generally, it's a good idea to avoid touching anything unless you're 100% sure it's okay. We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # Send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 5cfc0b71b00addfc2fe8d7aac6d1cc9659a18066 175 174 2021-10-22T17:28:45Z Alnis S 6 /* Summary */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for the UWROV mechanical team: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the satellite * Documentation & Operations - communicating the design to others and supporting the software & electrical team when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools does the team use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building a satellite? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # Send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) f5c8219a9a6f080b6747ecbebe8d8858901d3de0 176 175 2021-10-22T17:29:41Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for the UWROV mechanical team: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting the software & electrical team when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools does the team use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # Send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 64a09d23245f4323b7b6947d1eb9df0773ea6961 177 176 2021-10-22T17:42:53Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for the UWROV mechanical team: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting the software & electrical team when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools does the team use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # Send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 6799209db3c11d039780930ddd213392ecda1a37 179 177 2021-10-22T17:47:26Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for the UWROV mechanical team: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting the software & electrical team when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools does the team use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # Send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) bf7d20262696ada89efe03eb1548ec0928535548 180 179 2021-10-22T17:57:30Z Alnis S 6 /* How do I get started? */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for the UWROV mechanical team: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting the software & electrical team when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools does the team use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) ec989a7b815a7907a4042510cb7a9b691b5bffad 190 180 2021-10-23T17:36:19Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 9ef38310f85ca4b6dd9192ea03f811d35677066c 192 190 2021-10-24T03:43:32Z Alnis S 6 /* Resources */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) b9e75d17b92f5e70a039068482dfe4a6bd41c1ac 197 192 2021-10-27T19:23:24Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 * Name (left column): unique, but concise name for the project * Conversation (comment bubble): additional information, space to chat, etc. * Summary: a short description of the project's goals and requirements * Votes: vote for projects you think we should work on! ** This is how projects are prioritized ** Sometimes there will be projects that aren't interesting (few votes) but still need to be worked on * People: everyone working on the project * Tags: a unique #project_hashtag for finding related tasks, items, etc. ** Should remain unique in 5 years: if it's competition-specific, add the year ** Some projects may apply to multiple years (so a year isn't needed in the tag) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 Columns in the board: * Name (left column): unique, but concise name for the task * Conversation (comment bubble): additional information, space to chat, etc. * Subitems: smaller sections of the task to help break things up * Summary: a short description of the task's goals and requirements * Points: an estimate of how many hours of work it will take ** This should be a Fibonacci number: 1, 2, 3, 5, 8, 13, or 21 ** The idea is that it's a general sense of the size, not a perfect prediction ** Tasks larger than 21 points should be broken up into smaller ones * People: who is responsible for the task's completion? * Vote: vote for tasks you think are important! * Tags: a unique #project_hashtag for finding related tasks, items, projects, etc. (see project organization) Groups in the board: * Backlog: tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on * Ready: everything needed to start is provided, and all fields are filled out * Upcoming Iteration: tasks we want to work on in the next month are moved here === How are in-progress tasks tracked? === == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 270fa8c81f76749e0e98584e7f8c7d0425b48d3b 198 197 2021-10-27T19:30:33Z Alnis S 6 /* How are projects organized? */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 '''Columns''': * Name (left column): unique, but concise name for the project * Conversation (comment bubble): additional information, space to chat, etc. * Summary: a short description of the project's goals and requirements * Votes: vote for projects you think we should work on! ** This is how projects are prioritized ** Sometimes there will be projects that aren't interesting (few votes) but still need to be worked on * People: everyone working on the project * Tags: a unique #project_hashtag for finding related tasks, items, etc. ** Should remain unique in 5 years: if it's competition-specific, add the year ** Some projects may apply to multiple years (so a year isn't needed in the tag) '''Groups''': * === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 Columns in the board: * Name (left column): unique, but concise name for the task * Conversation (comment bubble): additional information, space to chat, etc. * Subitems: smaller sections of the task to help break things up * Summary: a short description of the task's goals and requirements * Points: an estimate of how many hours of work it will take ** This should be a Fibonacci number: 1, 2, 3, 5, 8, 13, or 21 ** The idea is that it's a general sense of the size, not a perfect prediction ** Tasks larger than 21 points should be broken up into smaller ones * People: who is responsible for the task's completion? * Vote: vote for tasks you think are important! * Tags: a unique #project_hashtag for finding related tasks, items, projects, etc. (see project organization) Groups in the board: * Backlog: tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on * Ready: everything needed to start is provided, and all fields are filled out * Upcoming Iteration: tasks we want to work on in the next month are moved here === How are in-progress tasks tracked? === == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) b3586aee4f7bfe97b66e9211f6281f8d92418433 199 198 2021-10-27T19:44:57Z Alnis S 6 /* How are projects organized? */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 Columns in the board: * Name (left column): unique, but concise name for the task * Conversation (comment bubble): additional information, space to chat, etc. * Subitems: smaller sections of the task to help break things up * Summary: a short description of the task's goals and requirements * Points: an estimate of how many hours of work it will take ** This should be a Fibonacci number: 1, 2, 3, 5, 8, 13, or 21 ** The idea is that it's a general sense of the size, not a perfect prediction ** Tasks larger than 21 points should be broken up into smaller ones * People: who is responsible for the task's completion? * Vote: vote for tasks you think are important! * Tags: a unique #project_hashtag for finding related tasks, items, projects, etc. (see project organization) Groups in the board: * Backlog: tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on * Ready: everything needed to start is provided, and all fields are filled out * Upcoming Iteration: tasks we want to work on in the next month are moved here === How are in-progress tasks tracked? === == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 0c37364e49c20c74cf827ef77e2861941ed4e812 200 199 2021-10-27T19:59:56Z Alnis S 6 /* How are projects organized? */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 Columns in the board: * Name (left column): unique, but concise name for the task * Conversation (comment bubble): additional information, space to chat, etc. * Subitems: smaller sections of the task to help break things up * Summary: a short description of the task's goals and requirements * Points: an estimate of how many hours of work it will take ** This should be a Fibonacci number: 1, 2, 3, 5, 8, 13, or 21 ** The idea is that it's a general sense of the size, not a perfect prediction ** Tasks larger than 21 points should be broken up into smaller ones * People: who is responsible for the task's completion? * Vote: vote for tasks you think are important! * Tags: a unique #project_hashtag for finding related tasks, items, projects, etc. (see project organization) Groups in the board: * Backlog: tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on * Ready: everything needed to start is provided, and all fields are filled out * Upcoming Iteration: tasks we want to work on in the next month are moved here === How are in-progress tasks tracked? === == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 46c839c7d48f3384e61cd59ddbc8e847dabdca35 6 22 178 2021-10-22T17:46:16Z Alnis S 6 wikitext text/x-wiki ROV21 (Nautilus) Render as of August 1st, 2021 222d657fd6ac1f5f0381d613e4c529b355f29d52 0 23 181 2021-10-22T18:05:25Z Alnis S 6 Created page with "Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 20th, 2021 === '''Goals''': * Set everyone..." wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 20th, 2021 === '''Goals''': * Set everyone up with all our accounts * Get mechanical team members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour * Set up monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home''': * Get started with Onshape - check out the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for ones you are interested in. This will guide our meeting next week when we decide what to work on. * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Please bring a laptop to the next meeting if you can 0045b40498cc3a28831482d76aa3f96dffaaf7a8 182 181 2021-10-22T18:07:52Z Alnis S 6 /* General Meetings */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical team members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour * Set up monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': * Get started with Onshape - check out the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for ones you are interested in. This will guide our meeting next week when we decide what to work on. * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Please bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 02008654ed2deef9cdf4f951d93bcb10eb7e38b7 183 182 2021-10-22T18:10:48Z Alnis S 6 /* October 20th, 2021 - First New Member Meeting! */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical team members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour * Set up monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': * Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for ones you are interested in. This will guide our meeting next week when we decide what to work on. * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Please bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * fbbd2145829c5e1879f19833b143102c05752793 184 183 2021-10-23T17:19:26Z Alnis S 6 /* October 20th, 2021 - First New Member Meeting! */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical team members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour * Set up monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': * Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * Please bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 83d7ab212e075f06aa3fada74b1fac4fda02fe0d 185 184 2021-10-23T17:21:24Z Alnis S 6 /* October 20th, 2021 - First New Member Meeting! */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical team members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': * Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * Please bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * c97be215f52e4c37511b1fcf0c9f96b8373d17df 186 185 2021-10-23T17:25:58Z Alnis S 6 /* October 20th, 2021 - First New Member Meeting! */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical team members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional/Recommended'' Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional/Recommended'' Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 65be59cd4f2d413d4d897608a8d445019fef6bc7 187 186 2021-10-23T17:29:27Z Alnis S 6 /* October 20th, 2021 - First New Member Meeting! */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical team members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'' Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'' Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * f96a1b30efc4fd9b01f106425ebb50aaa72ef095 188 187 2021-10-23T17:29:43Z Alnis S 6 /* October 20th, 2021 - First New Member Meeting! */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical team members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * ff26603c4850fcc39e777e06326a87e58ceee409 189 188 2021-10-23T17:33:48Z Alnis S 6 /* October 20th, 2021 - First New Member Meeting! */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * e8c8684c16676d98a1b6152752fb30b593d87d7a 191 189 2021-10-23T17:40:11Z Alnis S 6 /* October 20th, 2021 - First New Member Meeting! */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 4d1c0772f8c6835ea24ea9145cc4cedd4a542404 193 191 2021-10-25T22:42:57Z Alnis S 6 /* October 27th, 2021 - Kicking Off Some Work */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 888fa1e99a53ad6dfc96bdc702fe2d8dad14e576 196 193 2021-10-27T19:06:44Z Alnis S 6 wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to Monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * '''Do at home (after meeting)''': * === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 65fa86a284f6d94ff954480fe1e7a7e83a33eabd 0 2 194 82 2021-10-27T08:47:11Z Ajang304 9 wikitext text/x-wiki 💻🐒 * [[Software/Quick Start Guides | Quick Start Guides]] * [[Software/Starting Tutorial | Development Tutorial]] * [[Software/System | System]] * [[Software/Standards | Standards]] * [[Software/Learning Resources | Learning Resources]] * [[Software/In-house Challenge | In-house Challenge]] 093b846467fbd40a9f9e75b59eb0b8c0956a3927 0 24 195 2021-10-27T08:54:14Z Ajang304 9 Created page with "The following page is the specs for the in-house OceanUI Feature challenge. Using our current version of OceanUI, we challenge you to create a video chatting component which w..." wikitext text/x-wiki The following page is the specs for the in-house OceanUI Feature challenge. Using our current version of OceanUI, we challenge you to create a video chatting component which will be a new feature allowing multiple people to call over our interface. = In-house OceanUI Feature Challenge = There are three main components that needs to be developed for this challenge: # An API for the ROS network. # An API for socket.io to handle communications between the interface and the ROS network # An interface component or components that will display the camera and settings. The features of the video chatting component will be decided by you and can be anything that you believe will enhance the experience of the component. == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS API == The first thing that we recommend to create is the ROS API. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO API == SocketIO's API should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that translates all of the python network calls to javascript network calls. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] 7815a065b94738c02f6b97372a723f4418785a18 0 21 201 200 2021-10-27T20:01:01Z Alnis S 6 /* How are tasks that haven't been started tracked? */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on '''Ready''': everything needed to start is provided, and all fields are filled out '''Upcoming Iteration''': tasks we want to work on in the next month are moved here === How are in-progress tasks tracked? === == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 5acdeaee5063bdd0e3640f9f91116d9041e314fe 202 201 2021-10-27T20:01:24Z Alnis S 6 /* How are tasks that haven't been started tracked? */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 5c2737e3fa19e0d9785b6f9faec55a0087877f80 203 202 2021-10-27T20:13:23Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 4bcc8d10432a6988682d9d60ad6deb222ec2464d 221 203 2021-10-29T19:55:33Z Alnis S 6 /* Where do we work? */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 5-7 PM''' * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) 55422b70a4c63bff658866c56aa08e873321844b 226 221 2021-10-31T08:30:23Z Alnis S 6 /* Resources */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 5-7 PM''' * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) dd45caeb59da80b5a89159b611152bf746ef70bf 227 226 2021-11-03T23:17:49Z Alnis S 6 /* Project Management (monday.com) */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 5-7 PM''' * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) 761f152fd4243e872c67327a34d535e4022df754 229 227 2021-11-03T23:31:58Z Alnis S 6 /* Project Management (monday.com) */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 5-7 PM''' * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === Small: Can be completed in one week or less Parallel: Has as few dependencies as possible Actionable: There is a clear place to start Measurable: Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) 6c68d483ea280edd51d9def3a57dc689b60ee1a6 230 229 2021-11-03T23:32:12Z Alnis S 6 /* What makes a good task? */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 5-7 PM''' * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) 80196b181ce06049dee51a8bedcb286dce40590b 231 230 2021-11-03T23:32:55Z Alnis S 6 /* Google Drive */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 5-7 PM''' * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) b902dd492ed487226e7db142745225623221e531 232 231 2021-11-04T02:33:16Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) ca2b819576a7493d8e634c1cf500346b2392479a 233 232 2021-11-04T05:00:47Z Alnis S 6 /* Summary */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). === What are our goals for Autumn 2021? === We have two primary overarching goals: * Everyone has a baseline ability to use CAD * Everyone has designed and made something with the 3D printer and the waterjet On a more technical/deliverable level, we will make: * Underwater camera system prototype * Pressure hold that can go in the water * Prototype for each mechanism on ROV (can be manually powered) == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) 71abbb565ff56e3bce9047de0431d4cb6ccb36dd 239 233 2021-12-02T20:16:19Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. For our 2022 ROV design overview, please see [[ROV22 Design Overview]]. [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). === What are our goals for Autumn 2021? === We have two primary overarching goals: * Everyone has a baseline ability to use CAD * Everyone has designed and made something with the 3D printer and the waterjet On a more technical/deliverable level, we will make: * Underwater camera system prototype * Pressure hold that can go in the water * Prototype for each mechanism on ROV (can be manually powered) == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) 24a624190e9219c8e2b445afb3a411e1a35654b8 0 24 204 195 2021-10-28T00:08:08Z Ajang304 9 Updated specs for the challenge wikitext text/x-wiki The following page is the specs for the in-house OceanUI Feature challenge. Using our current version of OceanUI, we challenge you to create a video chatting component which will be a new feature allowing multiple people to call over our interface. = General Overview = There are three main components that needs to be developed for this challenge: # An API for the ROS network. # An API for socket.io to handle communications between the interface and the ROS network # An interface component or components that will display the camera and settings. The features of the video chatting component will be decided by you and can be anything that you believe will enhance the experience of the component. == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. == UI Component == Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] a216bd72b91d9cd078c3b3a139105ea81e982cf6 205 204 2021-10-28T00:17:05Z Gunarp 7 /* General Overview */ wikitext text/x-wiki The following page is the specs for the in-house OceanUI Feature challenge. Using our current version of OceanUI, we challenge you to create a video chatting component which will be a new feature allowing multiple people to call over our interface. = General Overview = The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team are entitled to 3 free snacks per person. == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. == UI Component == Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] 7dfd711093d8d4c09e9827519a0efc297e1e6130 206 205 2021-10-28T00:22:10Z Ajang304 9 /* UI Component */ wikitext text/x-wiki The following page is the specs for the in-house OceanUI Feature challenge. Using our current version of OceanUI, we challenge you to create a video chatting component which will be a new feature allowing multiple people to call over our interface. = General Overview = The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team are entitled to 3 free snacks per person. == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. == UI Component == Deliverables: * WebcamStream.js * WebcamStream.css * Register WebcamStream to the widget library. Instructions [https://uwrov.miraheze.org/wiki/Software/Starting_Tutorial here]. Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] c161a722ffed261326d443be837a2f4a7629addf 207 206 2021-10-28T00:24:12Z Ajang304 9 /* Server */ wikitext text/x-wiki The following page is the specs for the in-house OceanUI Feature challenge. Using our current version of OceanUI, we challenge you to create a video chatting component which will be a new feature allowing multiple people to call over our interface. = General Overview = The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team are entitled to 3 free snacks per person. == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. == UI Component == Deliverables: * WebcamStream.js * WebcamStream.css * Register WebcamStream to the widget library. Instructions [https://uwrov.miraheze.org/wiki/Software/Starting_Tutorial here]. Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == Deliverables: * webcam_stream_module.py * Update endpoints at main_server.py The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] ab75b6a0393a0dfdcf90b90ac6b9ebe6b8b702e6 208 207 2021-10-28T00:26:39Z Gunarp 7 wikitext text/x-wiki The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team will be entitled to 3 free snacks per person. = Timeline = * 10/27 -> Project Intro, Team Assignments * 11/03 -> Check-in 1 [General Design Outlined] * 11/10 -> Check-in 2 [At least 1 feature implemented] * 11/16 -> Implementations Complete * 11/17 -> Demo / Award Ceremony = Rules = 1. Implement your chatting app on our UI 2. Try your best to understand any code you end up using 3. There are no other rules :) = General Overview = == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. == UI Component == Deliverables: * WebcamStream.js * WebcamStream.css * Register WebcamStream to the widget library. Instructions [https://uwrov.miraheze.org/wiki/Software/Starting_Tutorial here]. Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == Deliverables: * webcam_stream_module.py * Update endpoints at main_server.py The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] 14d15afffd0fd66eb79cbab8f33bfcae219bd473 209 208 2021-10-28T00:28:35Z Gunarp 7 /* Rules */ wikitext text/x-wiki The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team will be entitled to 3 free snacks per person. = Timeline = * 10/27 -> Project Intro, Team Assignments * 11/03 -> Check-in 1 [General Design Outlined] * 11/10 -> Check-in 2 [At least 1 feature implemented] * 11/16 -> Implementations Complete * 11/17 -> Demo / Award Ceremony = Rules = # Implement your chatting app on our UI # Implement the project with your team members # Try your best to understand any code you end up using = General Overview = == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. == UI Component == Deliverables: * WebcamStream.js * WebcamStream.css * Register WebcamStream to the widget library. Instructions [https://uwrov.miraheze.org/wiki/Software/Starting_Tutorial here]. Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == Deliverables: * webcam_stream_module.py * Update endpoints at main_server.py The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] 6bc64a998ecec450129a1dc7d477d37f7c0714f6 213 209 2021-10-28T01:00:50Z Ajang304 9 wikitext text/x-wiki The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team will be entitled to 3 free snacks per person. = Timeline = * 10/27 -> Project Intro, Team Assignments * 11/03 -> Check-in 1 [General Design Outlined] * 11/10 -> Check-in 2 [At least 1 feature implemented] * 11/16 -> Implementations Complete * 11/17 -> Demo / Award Ceremony = Rules = # Implement your chatting app on our UI # Implement the project with your team members # Try your best to understand any code you end up using = General Overview = == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. [[File:Inhousespecs.png| View of Component in UI]] [[File:Inhousespecs-Page-2.drawio.png|Example of component layout]] We will be building an application in the form of an OceanUI component that allows two or multiple users to video call with each other. [[File:Inhousespecs-Page-3.drawio.png|Brief overview of network]] == UI Component == Deliverables: * WebcamStream.js * WebcamStream.css * Register WebcamStream to the widget library. Instructions [https://uwrov.miraheze.org/wiki/Software/Starting_Tutorial here]. Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. We will also be requiring a text chat to communicate text between the users like.a group chat. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == Deliverables: * webcam_stream_module.py * Update endpoints at main_server.py The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] e6e9a9fef9a054aab2dd6afa3288f4db270c7317 215 213 2021-10-28T01:06:30Z Ajang304 9 /* Requirements */ wikitext text/x-wiki The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team will be entitled to 3 free snacks per person. = Timeline = * 10/27 -> Project Intro, Team Assignments * 11/03 -> Check-in 1 [General Design Outlined] * 11/10 -> Check-in 2 [At least 1 feature implemented] * 11/16 -> Implementations Complete * 11/17 -> Demo / Award Ceremony = Rules = # Implement your chatting app on our UI # Implement the project with your team members # Try your best to understand any code you end up using = General Overview = == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. [[File:Inhousespecs.png| thumb | View of Component in UI]] [[File:Inhousespecs-Page-2.drawio (1).png|thumb|alt=Example of Webcam component|Example of Webcam component]] We will be building an application in the form of an OceanUI component that allows two or multiple users to video call with each other. [[File:Inhousespecs-Page-3.drawio.png|thumb|Brief overview of network]] == UI Component == Deliverables: * WebcamStream.js * WebcamStream.css * Register WebcamStream to the widget library. Instructions [https://uwrov.miraheze.org/wiki/Software/Starting_Tutorial here]. Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. We will also be requiring a text chat to communicate text between the users like.a group chat. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == Deliverables: * webcam_stream_module.py * Update endpoints at main_server.py The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] a9c002a9829b690d4f98bf5a836a2915488321fa 216 215 2021-10-28T01:09:03Z Ajang304 9 /* Requirements */ wikitext text/x-wiki The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team will be entitled to 3 free snacks per person. = Timeline = * 10/27 -> Project Intro, Team Assignments * 11/03 -> Check-in 1 [General Design Outlined] * 11/10 -> Check-in 2 [At least 1 feature implemented] * 11/16 -> Implementations Complete * 11/17 -> Demo / Award Ceremony = Rules = # Implement your chatting app on our UI # Implement the project with your team members # Try your best to understand any code you end up using = General Overview = == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. [[File:Inhousespecs.png| thumb | View of Component in UI]] [[File:Inhousespecs-Page-2.drawio (1).png|thumb|alt=Example of Webcam component|Example of Webcam component]] We will be building an application in the form of an OceanUI component that allows two or multiple users to video call with each other. The application will also allow users to communicate with each other through a text chatbox. [[File:Inhousespecs-Page-3.drawio.png|thumb|Brief overview of network]] == UI Component == Deliverables: * WebcamStream.js * WebcamStream.css * Register WebcamStream to the widget library. Instructions [https://uwrov.miraheze.org/wiki/Software/Starting_Tutorial here]. Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. We will also be requiring a text chat to communicate text between the users like.a group chat. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == Deliverables: * webcam_stream_module.py * Update endpoints at main_server.py The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] 4a462b0d870452e404c50a2b59842ebc27b492ff 217 216 2021-10-28T01:10:47Z Ajang304 9 wikitext text/x-wiki The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team will be entitled to 3 free snacks per person. = Timeline = * 10/27 -> Project Intro, Team Assignments * 11/03 -> Check-in 1 [General Design Outlined] * 11/10 -> Check-in 2 [At least 1 feature implemented] * 11/16 -> Implementations Complete * 11/17 -> Demo / Award Ceremony = Rules = # Implement your chatting app on our UI # Implement the project with your team members # Try your best to understand any code you end up using = General Overview = == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. [[File:Inhousespecs.png| thumb | View of Component in UI]] [[File:Inhousespecs-Page-2.drawio (1).png|thumb|alt=Example of Webcam component|Example of Webcam component]] We will be building an application in the form of an OceanUI component that: * allows two or multiple users to video call * allow users to communicate with each other through a text chatbox [[File:Inhousespecs-Page-3.drawio.png|thumb|Brief overview of network]] == UI Component == Your component must have 3 main functionalities. The ability to join the call, the ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call is specifically because there is no requirement for handling multiple separate calls for this challenge. However, you should still have the functionality of joining the call rather than immediately joining the call to make sure that the user expects to be part of the call rather than automatically joining. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. We will also be requiring a text chat to communicate text between the users like.a group chat. Another requirement is that your component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] fa2ee8b4597584a3dd97a9fef73323dbf83506b6 218 217 2021-10-28T01:13:53Z Ajang304 9 /* UI Component */ wikitext text/x-wiki The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team will be entitled to 3 free snacks per person. = Timeline = * 10/27 -> Project Intro, Team Assignments * 11/03 -> Check-in 1 [General Design Outlined] * 11/10 -> Check-in 2 [At least 1 feature implemented] * 11/16 -> Implementations Complete * 11/17 -> Demo / Award Ceremony = Rules = # Implement your chatting app on our UI # Implement the project with your team members # Try your best to understand any code you end up using = General Overview = == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. [[File:Inhousespecs.png| thumb | View of Component in UI]] [[File:Inhousespecs-Page-2.drawio (1).png|thumb|alt=Example of Webcam component|Example of Webcam component]] We will be building an application in the form of an OceanUI component that: * allows two or multiple users to video call * allow users to communicate with each other through a text chatbox [[File:Inhousespecs-Page-3.drawio.png|thumb|Brief overview of network]] == UI Component == Your component must have 2 main functionalities. The ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call would be a nice feature to add to ensure that the user has power over joining and leaving the call. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. We will also be requiring a text chat to communicate text between the users through a group chat. This will be a text box input to capture the user's text and a section to show the other user's text messages. Make sure that the component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A big suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] aab681dcc9248adaa92faa5774964e63642006ed 219 218 2021-10-28T01:17:41Z Ajang304 9 wikitext text/x-wiki The MATE ROV specs typically come out mid-late November, so we have some time on our hands as we wait for those to be released. To get everyone used to ROS, OceanUI, and designing/scoping out a project, we'll be dividing the subgroup into two teams to see who can create the best video chatting application using ROS and our UI! Members of the winning team will be entitled to 3 free snacks per person. = Timeline = * 10/27 -> Project Intro, Team Assignments * 11/03 -> Check-in 1 [General Design Outlined] * 11/10 -> Check-in 2 [At least 1 feature implemented] * 11/16 -> Implementations Complete * 11/17 -> Demo / Award Ceremony = Rules = # Implement your chatting app on our UI # Implement the project with your team members # Try your best to understand any code you end up using = General Overview = == Set up == The first thing to set up will be the docker and our main repository. Make sure to go through our development tutorial which can be found [https://uwrov.miraheze.org/w/index.php?title=Software/Starting_Tutorial here]. Most of the information on how to develop components will be found in the tutorial. Before starting, make sure to fork our main repository before starting to develop! == Planning == Before starting the project, we recommend that you plan out the features and API. * What sort of features do you want for this project? * Is it possible to implement? * How long would it take to implement? * How will the component look like visually? Once you have thought about all of these questions and have a general answer to it, you can start defining what will be implemented for this component. == ROS Communication== The first thing that we recommend to create a table of all of the information that will be passed through ROS. Although it is completely possible to create this component without ROS, we require that all method calls between computers and clients to be handled through the ROS network. This is to ensure that developers have experience with working with the ROS network and developing and managing an API for ROS. This is where all of the data that needs to be transferred between clients will be outlined. Here, we can get a grasp of the overall data structure required by our component. * What sort of data are we going to communicate between client and network? * How is the data structured? * What events will cause data to be sent or received? After defining the data structure, you should have a clear idea of how your component will logically function. == SocketIO == SocketIO should not be very complicated. The SocketIO server is only a proxy to communicate the information handled by the ROS network to the web client. This is specifically because to communicate with the ROS network essentially there is a proxy server that forwards all of the ROS data to our client and vice versa. Generally, this server takes in information from the ROS network to pass to the client and takes in information from the client to send to the ROS network. Some things to think about here are: * Will that data look different when sent to the client? * Is there data that is to be saved on the server? * Do we want to process the data before sending to the client or server? The python server also acts as a place to manage persistent data which will be helpful for some features that are to be developed. == OceanUI Widget == Finally, we take all the information that we want to communicate, and visualize it on our UI. We definitely recommend to have a rough draft of the visuals for the component before tackling this section. As shown in the tutorial, the UI is developed with React and consists of a Widget based architecture. Generally, all Widgets are modular which prevents influence between widgets on the UI. Each widget is displayed as a window and can be built up with html/css components. Using react, you will design a widget that visualizes the features that you have decided on. Some questions to ask for this section: * What will your widget look like? * Do we represent all the data we are using? * Is the interface intuitive to use? Remember that function is more important than style and try to get that working! = Requirements = Though this challenge is an open ended challenge, We will have a set of requirements that your component must fulfill. [[File:Inhousespecs.png| thumb | View of Component in UI]] [[File:Inhousespecs-Page-2.drawio (1).png|thumb|alt=Example of Webcam component|Example of Webcam component]] We will be building an application in the form of an OceanUI component that: * allows two or multiple users to video call * allow users to communicate with each other through a text chatbox [[File:Inhousespecs-Page-3.drawio.png|thumb|Brief overview of network]] == UI Component == Your component must have 2 main functionalities. The ability to stream the call, and the ability to send your stream to the call. This is the bare minimum for this challenge. The ability to join the call would be a nice feature to add to ensure that the user has power over joining and leaving the call. If you have an interest in handling multiple calls, I would recommend looking at the [https://socket.io/docs/v3/rooms/ socket.io room] functionality but will not be a requirement for the challenge. We will also be requiring a text chat to communicate text between the users through a group chat. This will be a text box input to capture the user's text and a section to show the other user's text messages. Make sure that the component must follow the directory pattern that currently exists; a component and all of the css must exist inside an isolated folder that can be considered as a single module. This means that your component should be isolated from other components unless through the "savedprops" handler. == Camera == You must have have the ability to stream camera feed from a computer source and send it to another client. A suggestion for this requirement is to also include camera settings that allow you to troubleshoot any camera connection issues and switch between cameras if there are multiple. For this challenge, we will not require the transmission of audio but would be an impressive feature that could be implemented. == Server == The biggest requirement for the server, as mentioned above, will be that all of the data between clients will need to be passed through the ROS communication network through publishers and subscribers. You will also need to make sure that your communication module is in a separate script in the format laid out in the tutorial. This means that all of the endpoint calls (sio.on) should happen within the main script. You are allowed to emit in your specific module, but there should not be any endpoint declarations within your module. == Stretch goals == Some feature ideas to add: * Camera Filters: * Multiple rooms for calls * Sound * drawing on component = Afterwords = Note that our current system is not perfect and will continuously be improved. If there are any bugs and/or suggestions to a better architecture, take notes and notify the leads so we can make improvements to the design! Good Luck with the challenge! = Tips = * Separating specific functions into small tasks makes things easier; if you're working with only text, keep it separate from video! * Make sure to leave some time to test out everything. * Knowing how data is structured helps to figure out how to manage and use the data. * [https://uwrov.miraheze.org/wiki/Software/Learning_Resources Learning resources] df7dd8b0807427e9cd29681781d313b03a0ddc15 6 25 210 2021-10-28T00:46:34Z Ajang304 9 wikitext text/x-wiki view of component in UI 9a8b05c9a26f6151981d24627683c6b6970b8117 6 26 211 2021-10-28T00:48:55Z Ajang304 9 wikitext text/x-wiki Example of Webcam component layout 9211661f5785c55985cafa868e365c40e8fab944 6 27 212 2021-10-28T00:59:55Z Ajang304 9 wikitext text/x-wiki Brief structure of Webcam Component network 6a325444eb289949e6d40d67e215ac4fb0d5b029 6 28 214 2021-10-28T01:05:49Z Ajang304 9 wikitext text/x-wiki Example of Webcam Component 38a3186db409a1530396fa5fdf752a5161166955 0 23 220 196 2021-10-29T19:53:47Z Alnis S 6 /* October 27th, 2021 - Kicking Off Some Work */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue Onshape tutorials * Get familiar with the background for your projects * Write actionable, precise goals for your projects and log as tasks in monday.com === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * bae75441509e975f18c5e51da2ef6b9ff1868853 222 220 2021-10-29T20:04:51Z Alnis S 6 /* October 27th, 2021 - Kicking Off Some Work */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue Onshape tutorials * Get familiar with the background for your projects * Write actionable, precise goals for your projects and log as tasks in monday.com * Read product demonstration and spec briefing https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf <br> Note: future competition info will be posted at https://materovcompetition.org/explorerspecs === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 9103684cbf6c28f22d90563208778ac2abb424ce 223 222 2021-10-29T20:17:59Z Alnis S 6 /* October 27th, 2021 - Kicking Off Some Work */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == General Meetings == === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read product demonstration and spec briefing https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf <br> Note: future competition info will be posted at https://materovcompetition.org/explorerspecs === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * ce4cb7c513d15ed1f82c6af89a8dc538f92d2326 224 223 2021-10-29T20:44:54Z Alnis S 6 /* General Meetings */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': '''Do at home (after meeting)''': === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 758183beec7100b00d7b25d277f61eeded1b9b16 225 224 2021-10-30T05:08:39Z Alnis S 6 /* Meeting Notes */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 528e87c251b8e4c947051c58871f7f51ce73fbb7 228 225 2021-11-03T23:21:43Z Alnis S 6 /* Meeting Notes */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === DATE - TITLE === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm * '''Meeting summary''': * '''Do at home (after meeting)''': * === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * f256dc607f7920e86ae3f4e9a5236bd7b828f3c0 234 228 2021-11-05T17:22:54Z Alnis S 6 /* DATE - TITLE */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === DATE - TITLE === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm * '''Meeting summary''': * Completed November roadmap for mechanical team * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 0c51588be8caed55852c671b256486fb6a748181 235 234 2021-11-05T17:23:42Z Alnis S 6 /* DATE - TITLE */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === November 3, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm * '''Meeting summary''': * Completed November roadmap for mechanical team * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * a99679d747549d08424855b427eb6ea54adc9895 236 235 2021-11-05T17:23:53Z Alnis S 6 /* November 3, 2021 - Autumn Roadmap */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm * '''Meeting summary''': * Completed November roadmap for mechanical team * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 5c54ca7527c1c36c6c6e8060daf13e4f5fd05ec2 237 236 2021-11-05T17:26:34Z Alnis S 6 /* November 3rd, 2021 - Autumn Roadmap */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * f5d04f51e34e10f49c2f4f6ee1ccfdb29fcb8fb4 238 237 2021-12-02T20:14:54Z Alnis S 6 /* Meeting Notes */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === December 1st, 2021 - ROV 2022 Design Kickoff === Attendance: Anna, Aisha, Teddy, Cassandra, Kenneth, Alnis from mechanical; +Hallie, Catherine, Peyton from business '''Goals''': * Wrap up introductory projects * Kick off design work on new ROV '''Meeting summary''': * MATE 2022 Explorer manual is not released yet, limiting what we could work on * Broke into mechanical, electrical, and software groups to begin planning for new design * Mechanical group worked on writing requirements for structure (pressure hold and frame) ** Notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit '''Do at home (after meeting)''': * People who were at the meeting: find or brainstorm/think up one structure design and evaluate it against our structure requirements ** https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit# * People who were not at the meeting: write requirements for the propulsion system, following the frame system as a guide === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 44720646d5e7ea5b8a8d9316faf13fed78d404d2 249 238 2021-12-05T00:15:50Z Alnis S 6 /* Meeting Notes */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === December 1st, 2021 - ROV 2022 Design Kickoff === Attendance: Anna, Aisha, Teddy, Cassandra, Kenneth, Alnis from mechanical; +Hallie, Catherine, Peyton from business '''Goals''': * Wrap up introductory projects * Kick off design work on new ROV '''Meeting summary''': * MATE 2022 Explorer manual is not released yet, limiting what we could work on * Broke into mechanical, electrical, and software groups to begin planning for new design * Mechanical group worked on writing requirements for structure (pressure hold and frame) ** Notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit '''Do at home (after meeting)''': * People who were at the meeting: find or brainstorm/think up one structure design and evaluate it against our structure requirements ** Meeting notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit# ** ROV design overview (condensed requirements): [[ROV22 Design Overview]] * People who were not at the meeting: write requirements for the propulsion system, following the frame system as a guide === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * e7fa9e9a458d29f6e463e59879704abb02da8a18 0 29 240 2021-12-02T20:32:02Z Alnis S 6 Created page with "This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!class="unsortable"|Nice to have!!class="unsortable"|Avo..." wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!class="unsortable"|Nice to have!!class="unsortable"|Avoid if possible |- | Overall ROV || * Can deploy through a 1-meter square * Weight limit (check for the exact value, probably 20 kg) || * Modularity and adjustability * Easy to develop and design * Easy to carry/move * Robust materials (no zip ties!) || * Overcomplication * Difficult to manufacture * Overspending our budget * Comes apart when shipping (not fragile) |- | Structure || * Housing the electronics * Thruster mounting * Protect delicate systems * Place to mount a manipulator * Balanced & manually re-balanceable * Neutrally buoyant * Camera mounting (don’t have frame block it) * Can stand on its own * Camera view of gripper || * Mounting for external sensors || * Manipulator situation (conflicting subsystems) |} 2e449fdd0beeceeaabc4c0d4a5efb44c87dd0184 241 240 2021-12-02T20:38:01Z Alnis S 6 wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!Nice to have!!Avoid if possible |- | Overall ROV || * Can deploy through a 1-meter square * Weight limit (check for the exact value, probably 20 kg) || * Modularity and adjustability * Easy to develop and design * Easy to carry/move * Robust materials (no zip ties!) || * Overcomplication * Difficult to manufacture * Overspending our budget * Comes apart when shipping (not fragile) |- | Structure || * Housing the electronics * Thruster mounting * Protect delicate systems * Place to mount a manipulator * Balanced & manually re-balanceable * Neutrally buoyant * Camera mounting (don’t have frame block it) * Can stand on its own * Camera view of gripper || * Mounting for external sensors || * Manipulator situation (conflicting subsystems) |} ca363bb562af75399b99efef7ed3018c27ccba7c 242 241 2021-12-02T20:53:18Z Alnis S 6 wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!style="vertical-align: top;"|Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |} 3a2c0777687b19e7472cbebe722e0a3efd724d7e 243 242 2021-12-02T21:13:11Z Alnis S 6 wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | !Alnis!!TBD!!To do!!None!!Yes |-style="vertical-align: top;" |} === Propulsion === === Manipulator === == 1d98d8a9c275631e63cd32ae97721c5cf7b162ce 244 243 2021-12-02T21:14:24Z Alnis S 6 /* Structure */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Alnis | TBD To do | None | Yes |-style="vertical-align: top;" |} === Propulsion === === Manipulator === == 66dffaac34379e8d0d58d9f73f4ee19367cb11ff 245 244 2021-12-02T21:14:41Z Alnis S 6 /* Design Concepts */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Alnis | TBD | To do | None | Yes |-style="vertical-align: top;" |} === Propulsion === === Manipulator === 311f18ff783afabedb2db888bf92763fcfe213a2 246 245 2021-12-05T00:07:04Z Alnis S 6 /* Requirements */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Alnis | TBD | To do | None | Yes |-style="vertical-align: top;" |} === Propulsion === === Manipulator === f272335dcb76f099320b3589587baf353313d4d3 247 246 2021-12-05T00:08:57Z Alnis S 6 /* Design Concepts */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Alnis | TBD | To do | None | Yes |-style="vertical-align: top;" |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} 2f3376f26a8b37a6046ab5f67187c957a131de5f 248 247 2021-12-05T00:13:53Z Alnis S 6 /* Structure */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Alnis | [[Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} d56f6e51ca648c8e7556e537ff8dfb7a7dc9da89 250 248 2021-12-05T00:16:39Z Alnis S 6 /* Structure */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} c643b096b33773b403c95489e96a40de0fdc331d 0 21 251 239 2021-12-05T00:26:26Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. For our 2022 ROV design overview, please see [[ROV22 Design Overview]]. Useful templates: * [[Design Concept Template]] [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). === What are our goals for Autumn 2021? === We have two primary overarching goals: * Everyone has a baseline ability to use CAD * Everyone has designed and made something with the 3D printer and the waterjet On a more technical/deliverable level, we will make: * Underwater camera system prototype * Pressure hold that can go in the water * Prototype for each mechanism on ROV (can be manually powered) == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) d512b57128465b1dd1fe9d9ca11a9d393dd12ea1 285 251 2021-12-19T00:06:18Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. For our 2022 ROV design overview, please see [[ROV22 Design Overview]]. Useful templates: * [[Design Concept Template]] <em>“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry, Airman's Odyssey</em> [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). === What are our goals for Autumn 2021? === We have two primary overarching goals: * Everyone has a baseline ability to use CAD * Everyone has designed and made something with the 3D printer and the waterjet On a more technical/deliverable level, we will make: * Underwater camera system prototype * Pressure hold that can go in the water * Prototype for each mechanism on ROV (can be manually powered) == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) 1e427ef29b121f3233e10e67abf115b54de0adcb 299 285 2022-01-18T02:07:17Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. For our 2022 ROV design overview, please see [[ROV22 Design Overview]]. For a list of mechanical learning resources, please see [[Mechanical Learning Resources]]. Useful templates: * [[Design Concept Template]] <em>“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry, Airman's Odyssey</em> [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). === What are our goals for Autumn 2021? === We have two primary overarching goals: * Everyone has a baseline ability to use CAD * Everyone has designed and made something with the 3D printer and the waterjet On a more technical/deliverable level, we will make: * Underwater camera system prototype * Pressure hold that can go in the water * Prototype for each mechanism on ROV (can be manually powered) == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) 72df0c7529e511a04aa0fc5d369e39ab465bcdff 0 30 252 2021-12-05T00:26:44Z Alnis S 6 Created page with "Concept by Person Name for Project; requirements found here: link to wiki page Summary goes here == Overview == The description of the proposed solution goes here. Images,..." wikitext text/x-wiki Concept by Person Name for Project; requirements found here: link to wiki page Summary goes here == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == 3537500236231d3d51fbbe458f17545e6b25b0f2 2 31 253 2021-12-05T00:27:56Z Alnis S 6 Created page with "Alnis Smidchens is the mechanical lead of UWROV. Contact: * alnis@uw.edu * alnis#0001 on Discord * (206) 548-6900" wikitext text/x-wiki Alnis Smidchens is the mechanical lead of UWROV. Contact: * alnis@uw.edu * alnis#0001 on Discord * (206) 548-6900 b89953999173b39a436486abaf611dd9facafefd 0 1 254 173 2021-12-05T00:29:09Z Alnis S 6 /* Welcome to {{SITENAME}}! */ wikitext text/x-wiki __NOTOC__ == Welcome to {{SITENAME}}! == Welcome to the UWROV wiki! Check out our subteam wiki areas: * [[Software]] * [[Mechanical]] Project page for our 2022 MATE ROV: [[ROV22]] === Contributing to the Wiki === * <span class="plainlinks">[[mw:Special:MyLanguage/Help:Contents|MediaWiki guide (e.g. navigation, editing, deleting pages, blocking users)]] * [[meta:FAQ|Miraheze FAQ]] * [[meta:Request features|Request settings changes on your wiki. (Extensions and Logo/Favicon changes should be done through Special:ManageWiki on your wiki]]. df0f4d1adc7c56300f298f61ab0097e90f4f7906 266 254 2021-12-05T23:46:23Z Ronankau 34 /* Welcome to {{SITENAME}}! */ wikitext text/x-wiki __NOTOC__ == Welcome to {{SITENAME}}! == Welcome to the UWROV wiki! Check out our subteam wiki areas: * [[Software]] * [[Mechanical]] Project page for our 2022 MATE ROV: [[ROV22]] === Contributing to the Wiki === * <span class="plainlinks">[[mw:Special:MyLanguage/Help:Contents|MediaWiki guide (e.g. navigation, editing, deleting pages, blocking users)]] * [[meta:FAQ|Miraheze FAQ]] * [[meta:Request features|Request settings changes on your wiki. (Extensions and Logo/Favicon changes should be done through Special:ManageWiki on your wiki]]. 9e6462ed721a96c51619806d05dd1a7f13b80a5b 267 266 2021-12-05T23:46:40Z Ronankau 34 /* Welcome to {{SITENAME}}! */ wikitext text/x-wiki __NOTOC__ == Welcome to {{SITENAME}}! == Welcome to the UWROV wiki! Check out our subteam wiki areas: * [[Software]] * [[Mechanical]] Project page for our 2022 MATE ROV: [[ROV22]] === Contributing to the Wiki === * <span class="plainlinks">[[mw:Special:MyLanguage/Help:Contents|MediaWiki guide (e.g. navigation, editing, deleting pages, blocking users)]] * [[meta:FAQ|Miraheze FAQ]] * [[meta:Request features|Request settings changes on your wiki. (Extensions and Logo/Favicon changes should be done through Special:ManageWiki on your wiki]]. df0f4d1adc7c56300f298f61ab0097e90f4f7906 0 32 255 2021-12-05T00:29:58Z Alnis S 6 Created page with "Mechanical design overview: [[ROV22 Design Overview]]" wikitext text/x-wiki Mechanical design overview: [[ROV22 Design Overview]] ce7dc4a7ebce32c7e370ab4175eb46457a933c38 0 33 256 2021-12-05T00:30:14Z Alnis S 6 Created page with "Concept by [[User:Alnis S|Alnis S]] for [[ROV22]]; requirements found here: [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] Summary goes here == Overview == Th..." wikitext text/x-wiki Concept by [[User:Alnis S|Alnis S]] for [[ROV22]]; requirements found here: [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] Summary goes here == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == 2aa997ba5537eb1ba065e08bd38297ae7c12461f 283 256 2021-12-13T21:23:55Z Alnis S 6 wikitext text/x-wiki Concept by [[User:Alnis S|Alnis S]] for [[ROV22]]; requirements found here: [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] The core idea: simplify the structure to a single part! Rather than worrying about the structure accommodating different subsystems, it's easy if the structure is simply full of mounting points and subsystems can be shuffled around and moved as needed. This design prioritizes modularity, ease of modification, and simplicity over good looks or structural efficiency. == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. [[File:ROV Concept Big Ol Plate CAD Image.png|thumb|Mockup of layout of ROV using Big Ol' Plate concept]] The idea behind the "Big Ol' Plate" concept is that rather than constructing the structure out of multiple components and thinking in three dimensions, what if we just had a big, beefy plate with lots of mounting points (holes on the goBILDA pattern?), then mounted each component individually to the plate? That way, the chain of structural connection is very simple: every component is mounted at a single point, so taking anything off is very simple. Additionally, it automatically gives a lot of design flexibility for late-stage design changes since anything can be shifted around easily, from propulsion through the manipulator. Finally, because most of the structure's mass is very low on the ROV, it automatically aids with balancing a lot. == Advantages == === In general === * Very low part count * Easy to tweak the positions of subsystems * Open-ended manipulator and camera mounting on the front * Few if any restrictions on design choices for propulsion, manipulator, etc. === Versus previous UWROV designs === * Less steps to take components off for repairs * Easy to adjust mounting of any subsystem * Great camera and manipulator mounting options === Versus other industry/commercial/published options === * Super cheap and simple (10x cheaper + less parts than BlueROV frame: https://bluerobotics.com/store/rov/bluerov2-components-spares/brov2-asm-frame-r1-rp/) * == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == b26ede9ef265d7fb3ea6eee30a55ffb48170bc16 286 283 2022-01-02T03:32:40Z Alnis S 6 wikitext text/x-wiki Concept by [[User:Alnis S|Alnis S]] for [[ROV22]]; requirements found here: [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] The core idea: simplify the structure to a single part! Rather than worrying about the structure accommodating different subsystems, it's easy if the structure is simply full of mounting points and subsystems can be shuffled around and moved as needed. This design prioritizes modularity, ease of modification, and simplicity over good looks or structural efficiency. == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. [[File:ROV Concept Big Ol Plate CAD Image.png|thumb|Mockup of layout of ROV using Big Ol' Plate concept]] The idea behind the "Big Ol' Plate" concept is that rather than constructing the structure out of multiple components and thinking in three dimensions, what if we just had a big, beefy plate with lots of mounting points (holes on the goBILDA pattern?), then mounted each component individually to the plate? That way, the chain of structural connection is very simple: every component is mounted at a single point, so taking anything off is very simple. Additionally, it automatically gives a lot of design flexibility for late-stage design changes since anything can be shifted around easily, from propulsion through the manipulator. Finally, because most of the structure's mass is very low on the ROV, it automatically aids with balancing a lot. == Advantages == === In general === * Very low part count * Easy to tweak the positions of subsystems * Open-ended manipulator and camera mounting on the front * Few if any restrictions on design choices for propulsion, manipulator, etc. * Low center of mass by default === Versus previous UWROV designs === * Less steps to take components off for repairs * Easy to adjust mounting of any subsystem * Great camera and manipulator mounting options === Versus other industry/commercial/published options === * Super cheap and simple (10x cheaper + less parts than BlueROV frame: https://bluerobotics.com/store/rov/bluerov2-components-spares/brov2-asm-frame-r1-rp/) * Easier to attach equipment than most off-the-shelf ROVs due to large number of consistent mounting points == Disadvantages == === In general === * Likely the flimsiest option possible * Lots of drag when moving up and down * Some propulsion layouts may be less effective due to plate blocking movement of water === Versus previous UWROV designs === * Less vertically maneuverable, and we already had some issues with this previously when a motor went out at worlds * Tether strain relief does not have a clear place to attach === Versus other industry/commercial/published options === * Unproven design not seen elsewhere * Not elegant/optimized == See also == 86acaeff3ba0385533e7638ce29ba989f31134f7 0 23 257 249 2021-12-05T00:30:49Z Alnis S 6 /* December 1st, 2021 - ROV 2022 Design Kickoff */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === December 1st, 2021 - ROV 2022 Design Kickoff === Attendance: Anna, Aisha, Teddy, Cassandra, Kenneth, Alnis from mechanical; +Hallie, Catherine, Peyton from business '''Goals''': * Wrap up introductory projects * Kick off design work on new ROV '''Meeting summary''': * MATE 2022 Explorer manual is not released yet, limiting what we could work on * Broke into mechanical, electrical, and software groups to begin planning for new design * Mechanical group worked on writing requirements for structure (pressure hold and frame) ** Notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit '''Do at home (after meeting)''': * People who were at the meeting: find or brainstorm/think up one structure design and evaluate it against our structure requirements ** Meeting notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit# ** ROV design overview (condensed requirements): [[ROV22 Design Overview]] ** Copy the [[Design Concept Template]] to write up your work * People who were not at the meeting: write requirements for the propulsion system, following the frame system as a guide === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * e7487f8ebb7e076dbb4f187c6e6606d4e2f1913a 289 257 2022-01-03T03:45:50Z Alnis S 6 /* Meeting Notes */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === January 2nd, 2022 - Winter Quarter Kickoff === Discord announcement: https://discord.com/channels/753423399224606720/753423661104496709/926642307304923186 '''Goals''': * Review subsystem requirements - see [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] * Present design concepts for ROV structure/overall design * Select a design direction for the ROV as a whole * Assign and split into project groups to plan project work '''Meeting summary''': * Reviewed requirements and presented design concepts ** Each person shared one benefit they saw of each concept after it was presented ** Independently identified three key design elements to include * Made key design decisions to guide work and scope for 1.0 iteration * Assigned projects and split into breakout rooms for each project '''Do at home (after meeting)''': * Be confident in all functional requirements * Familiarize yourself with the MATE manual * Have a detailed on-paper plan of what you want to build/your design * Specific targets: ** ROV Core: detailed layout of structure & systems ** Manipulator: each person has one prototype concept they want to test out ** Float: each person has one sketch/concept of a float (try to make it look fundamentally different from the current one) ** Miscellaneous: create a block diagram of the surface station and work on importing a basic ROV into Gazebo === December 1st, 2021 - ROV 2022 Design Kickoff === Attendance: Anna, Aisha, Teddy, Cassandra, Kenneth, Alnis from mechanical; +Hallie, Catherine, Peyton from business '''Goals''': * Wrap up introductory projects * Kick off design work on new ROV '''Meeting summary''': * MATE 2022 Explorer manual is not released yet, limiting what we could work on * Broke into mechanical, electrical, and software groups to begin planning for new design * Mechanical group worked on writing requirements for structure (pressure hold and frame) ** Notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit '''Do at home (after meeting)''': * People who were at the meeting: find or brainstorm/think up one structure design and evaluate it against our structure requirements ** Meeting notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit# ** ROV design overview (condensed requirements): [[ROV22 Design Overview]] ** Copy the [[Design Concept Template]] to write up your work * People who were not at the meeting: write requirements for the propulsion system, following the frame system as a guide === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * bab33fd8bdd02aa2b15fd4b303911478b52152b6 290 289 2022-01-03T03:48:45Z Alnis S 6 /* Meeting Notes */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === January 2nd, 2022 - Winter Quarter Kickoff === Discord announcement: https://discord.com/channels/753423399224606720/753423661104496709/926642307304923186 '''Goals''': * Review subsystem requirements - see [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] * Present design concepts for ROV structure/overall design * Select a design direction for the ROV as a whole * Assign and split into project groups to plan project work '''Meeting summary''': * Reviewed requirements and presented design concepts ** Each person shared one benefit they saw of each concept after it was presented ** Independently identified three key design elements to include * Made key design decisions to guide work and scope for [[ROV22 Design Overview#1.0 Iteration|1.0 Iteration]] * Assigned projects and split into breakout rooms for each project '''Do at home (after meeting)''': * Familiarize yourself with the MATE manual * Be confident in all functional project requirements * Have a detailed on-paper plan of what you want to build/your design for the project * Specific targets: ** ROV Core: detailed layout of structure & systems ** Manipulator: each person has one prototype concept they want to test out ** Float: each person has one sketch/concept of a float (try to make it look fundamentally different from the current one) ** Miscellaneous: create a block diagram of the surface station and work on importing a basic ROV into Gazebo === December 1st, 2021 - ROV 2022 Design Kickoff === Attendance: Anna, Aisha, Teddy, Cassandra, Kenneth, Alnis from mechanical; +Hallie, Catherine, Peyton from business '''Goals''': * Wrap up introductory projects * Kick off design work on new ROV '''Meeting summary''': * MATE 2022 Explorer manual is not released yet, limiting what we could work on * Broke into mechanical, electrical, and software groups to begin planning for new design * Mechanical group worked on writing requirements for structure (pressure hold and frame) ** Notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit '''Do at home (after meeting)''': * People who were at the meeting: find or brainstorm/think up one structure design and evaluate it against our structure requirements ** Meeting notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit# ** ROV design overview (condensed requirements): [[ROV22 Design Overview]] ** Copy the [[Design Concept Template]] to write up your work * People who were not at the meeting: write requirements for the propulsion system, following the frame system as a guide === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 540fed5214da4ba2ee9ea90a63d029fdb06270d8 293 290 2022-01-03T03:55:44Z Alnis S 6 /* January 2nd, 2022 - Winter Quarter Kickoff */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === January 2nd, 2022 - Winter Quarter Kickoff === Discord announcement: https://discord.com/channels/753423399224606720/753423661104496709/926642307304923186 '''Goals''': * Review subsystem requirements - see [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] * Present design concepts for ROV structure/overall design * Select a design direction for the ROV as a whole * Assign and split into project groups to plan project work (set up meeting times, review goals for this week, assign responsibilities, kick off design work) '''Meeting summary''': * Reviewed requirements and presented design concepts ** Each person shared one benefit they saw of each concept after it was presented ** Independently identified three key design elements to include * Made key design decisions to guide work and scope for [[ROV22 Design Overview#1.0 Iteration|1.0 Iteration]] * Assigned projects and split into breakout rooms for each project '''Do at home (after meeting)''': * Familiarize yourself with the MATE manual * Be confident in all functional project requirements * Have a detailed on-paper plan of what you want to build/your design for the project * Specific targets: ** ROV Core: detailed layout of structure & systems ** Manipulator: each person has one prototype concept they want to test out ** Float: each person has one sketch/concept of a float (try to make it look fundamentally different from the current one) ** Miscellaneous: create a block diagram of the surface station and work on importing a basic ROV into Gazebo === December 1st, 2021 - ROV 2022 Design Kickoff === Attendance: Anna, Aisha, Teddy, Cassandra, Kenneth, Alnis from mechanical; +Hallie, Catherine, Peyton from business '''Goals''': * Wrap up introductory projects * Kick off design work on new ROV '''Meeting summary''': * MATE 2022 Explorer manual is not released yet, limiting what we could work on * Broke into mechanical, electrical, and software groups to begin planning for new design * Mechanical group worked on writing requirements for structure (pressure hold and frame) ** Notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit '''Do at home (after meeting)''': * People who were at the meeting: find or brainstorm/think up one structure design and evaluate it against our structure requirements ** Meeting notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit# ** ROV design overview (condensed requirements): [[ROV22 Design Overview]] ** Copy the [[Design Concept Template]] to write up your work * People who were not at the meeting: write requirements for the propulsion system, following the frame system as a guide === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * f4b5d9ed9fb74856b6318e247ba0f1b87a6c0aff 294 293 2022-01-03T03:56:13Z Alnis S 6 /* January 2nd, 2022 - Winter Quarter Kickoff */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === January 2nd, 2022 - Winter Quarter Kickoff === Discord announcement: https://discord.com/channels/753423399224606720/753423661104496709/926642307304923186 '''Goals''': * Review subsystem requirements - see [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] * Present design concepts for ROV structure/overall design * Select a design direction for the ROV as a whole * Assign and split into project groups to plan project work (set up meeting times, review goals for this week, assign responsibilities, kick off design work) '''Meeting summary''': * Reviewed requirements and presented design concepts ** Each person shared one benefit they saw of each concept after it was presented ** Independently identified three key design elements to include * Made key design decisions to guide work and scope for [[ROV22 Design Overview#1.0 Iteration|1.0 Iteration]] * Assigned projects and split into breakout rooms for each project '''Do at home (after meeting)''': * Familiarize yourself with the MATE manual * Be confident in all functional project requirements * Have a detailed on-paper plan of what you want to build/your design for the project * Specific targets: ** ROV Core: detailed layout of structure & systems ** Manipulator: each person has one prototype concept they want to test out ** Float: each person has one sketch/concept of a float (try to make it look fundamentally different from the current one) ** Miscellaneous: create a block diagram of the surface station and work on importing a basic ROV into Gazebo === December 1st, 2021 - ROV 2022 Design Kickoff === Attendance: Anna, Aisha, Teddy, Cassandra, Kenneth, Alnis from mechanical; +Hallie, Catherine, Peyton from business '''Goals''': * Wrap up introductory projects * Kick off design work on new ROV '''Meeting summary''': * MATE 2022 Explorer manual is not released yet, limiting what we could work on * Broke into mechanical, electrical, and software groups to begin planning for new design * Mechanical group worked on writing requirements for structure (pressure hold and frame) ** Notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit '''Do at home (after meeting)''': * People who were at the meeting: find or brainstorm/think up one structure design and evaluate it against our structure requirements ** Meeting notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit# ** ROV design overview (condensed requirements): [[ROV22 Design Overview]] ** Copy the [[Design Concept Template]] to write up your work * People who were not at the meeting: write requirements for the propulsion system, following the frame system as a guide === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * c3cfae123966f7c32cf53b28cdd1ebd97d198431 296 294 2022-01-03T04:10:39Z Alnis S 6 /* January 2nd, 2022 - Winter Quarter Kickoff */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === January 2nd, 2022 - Winter Quarter Kickoff === Discord announcement: https://discord.com/channels/753423399224606720/753423661104496709/926642307304923186 '''Goals''': * Review subsystem requirements - see [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] * Present design concepts for ROV structure/overall design * Select a design direction for the ROV as a whole * Assign and split into project groups to plan project work (set up meeting times, review goals for this week, assign responsibilities, kick off design work) '''Meeting summary''': * Reviewed requirements and presented design concepts ** Each person shared one benefit they saw of each concept after it was presented ** Independently identified three key design elements to include ** Shared our three elements and compiled into a list * Made key design decisions to guide work and scope for [[ROV22 Design Overview#1.0 Iteration|1.0 Iteration]] * Assigned projects and split into breakout rooms for each project '''Do at home (after meeting)''': * Familiarize yourself with the MATE manual * Be confident in all functional project requirements * Have a detailed on-paper plan of what you want to build/your design for the project * Specific targets: ** ROV Core: detailed layout of structure & systems ** Manipulator: each person has one prototype concept they want to test out ** Float: each person has one sketch/concept of a float (try to make it look fundamentally different from the current one) ** Miscellaneous: create a block diagram of the surface station and work on importing a basic ROV into Gazebo === December 1st, 2021 - ROV 2022 Design Kickoff === Attendance: Anna, Aisha, Teddy, Cassandra, Kenneth, Alnis from mechanical; +Hallie, Catherine, Peyton from business '''Goals''': * Wrap up introductory projects * Kick off design work on new ROV '''Meeting summary''': * MATE 2022 Explorer manual is not released yet, limiting what we could work on * Broke into mechanical, electrical, and software groups to begin planning for new design * Mechanical group worked on writing requirements for structure (pressure hold and frame) ** Notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit '''Do at home (after meeting)''': * People who were at the meeting: find or brainstorm/think up one structure design and evaluate it against our structure requirements ** Meeting notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit# ** ROV design overview (condensed requirements): [[ROV22 Design Overview]] ** Copy the [[Design Concept Template]] to write up your work * People who were not at the meeting: write requirements for the propulsion system, following the frame system as a guide === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * 833fe67c77d2bf4d70b24d568dd649c9f21c8721 297 296 2022-01-03T04:11:09Z Alnis S 6 /* January 2nd, 2022 - Winter Quarter Kickoff */ wikitext text/x-wiki Here, you can find goals, a meeting summary, and action items to do at home from each [[Mechanical]] meeting. == Meeting Notes == === January 2nd, 2022 - Winter Quarter Kickoff === Discord announcement: https://discord.com/channels/753423399224606720/753423661104496709/926642307304923186 '''Goals''': * Review subsystem requirements - see [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] * Present design concepts for ROV structure/overall design * Select a design direction for the ROV as a whole * Assign and split into project groups to plan project work (set up meeting times, review goals for this week, assign responsibilities, kick off design work) '''Meeting summary''': * Reviewed requirements and presented design concepts ** Each person shared one benefit they saw of each concept after it was presented ** Independently identified three key design elements to include ** Shared our three elements and compiled into a list * Made key design decisions to guide work and scope for [[ROV22 Design Overview#1.0 Iteration|1.0 Iteration]] * Assigned projects and split into breakout rooms for each project '''Do at home (after meeting)''': * Familiarize yourself with the MATE manual * Be confident in all functional project requirements * Have a detailed on-paper plan of what you want to build/your design for the project * Specific targets: ** ROV Core: detailed layout of structure & systems ** Manipulator: each person has one prototype concept they want to test out ** Float: each person has one sketch/concept of a float (try to make it look fundamentally different from the current one) ** Miscellaneous: create a block diagram of the surface station and work on importing a basic ROV into Gazebo === December 1st, 2021 - ROV 2022 Design Kickoff === Attendance: Anna, Aisha, Teddy, Cassandra, Kenneth, Alnis from mechanical; +Hallie, Catherine, Peyton from business '''Goals''': * Wrap up introductory projects * Kick off design work on new ROV '''Meeting summary''': * MATE 2022 Explorer manual is not released yet, limiting what we could work on * Broke into mechanical, electrical, and software groups to begin planning for new design * Mechanical group worked on writing requirements for structure (pressure hold and frame) ** Notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit '''Do at home (after meeting)''': * People who were at the meeting: find or brainstorm/think up one structure design and evaluate it against our structure requirements ** Meeting notes document: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit# ** ROV design overview (condensed requirements): [[ROV22 Design Overview]] ** Copy the [[Design Concept Template]] to write up your work * People who were not at the meeting: write requirements for the propulsion system, following the frame system as a guide === November 3rd, 2021 - Autumn Roadmap === '''Goals''': * Establish a clear, actionable roadmap for November for every project & member ** Review tasks in the [https://uwrov.monday.com/boards/1608728974 backlog] ** Refine and write tasks as needed ** Prioritize and assign tasks * Discuss possible new meeting time: ending at 8 PM <br> Purpose: software ends then, so we can walk home in larger groups * Brainstorm learning topics * Formalize mechanical team goals for the autumn ** Based on [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit 2021 Review] document & Friday brainstorm '''Meeting summary''': * Completed November roadmap for mechanical team ** If you were not at the meeting, please finish writing 3-4 tasks based on "[https://uwrov.miraheze.org/wiki/Mechanical#What_makes_a_good_task? what makes a good task?" ** Look at the backlog board for examples of what others wrote * Decided on new meeting time: 6-7 PM Wednesdays; lab open 5-8 PM (come for two hours please!) * Announcement: please submit learning topics * Formalized [https://uwrov.miraheze.org/wiki/Mechanical#What_are_our_goals_for_Autumn_2021? goals for the autumn 2021 quarter] * Cleared floors--hopefully will be cleaned by UW facilities! '''Do at home (after meeting)''': * Send at least one specific topic you want to learn about to Alnis * Finish writing & refining 3-4 tasks for each project you're on * Finish CAD tutorials if still working on them * Move a task from the backlog board to the iteration board and start working on it === October 29th, 2021 - Goal Setting for Projects and Competition Overview === '''Goals''': * Set 3-4 actionable, precise goals per member per project (see previous meeting action items) * Review published materials about this year's competition * Set general goals for the mechanical team <br> See [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit#heading=h.av5ijap90gjx ROV 2021 Review document] for background & starting point '''Meeting summary''': * Discussed what makes a good goal/task * Talked about what we know about this year's challenge so far * Created team goals to help steer UWROV's mechanical team for the quarter [https://docs.google.com/document/d/1TTmd9bvjWy5DOVWaNF0UoVfSB16XbzLbtu6mZNgq4h0/edit# ROV 2021 Review] '''Do at home (after meeting)''': * Continue work on action items from October 27th. === October 27th, 2021 - Kicking Off Some Work === '''Goals''': * Introductions (should have happened in the first meeting) * Tour of the Ocean Sciences Building and test pool * Introduction to monday.com and Onshape organizational structures * Plan for if/how we want to meet outside of the general meeting * Initial project selections & kicking off work '''Meeting summary''': * Introduced with name, year, major, and fun fact * Checked out OSB * Quick overview of monday.com and Onshape * Decided on alternative mechanical meeting time: 5:00 PM Fridays; hybrid (Discord/OCE 118) * Voted on projects to select most interesting ones * Self-assigned to 1-3 projects, 1-3 people per project * Broke off into small groups to start working on projects '''Do at home (after meeting)''': * Continue/start Onshape tutorials (see previous meeting action items) * Get familiar with the background for your projects ** Why is this project relevant and important to our team? ** What does success look like for this project? ** What do I want to get out of this project? * Write actionable, precise goals for your projects and log as tasks: https://uwrov.monday.com/boards/1608728974 ** Ensure title, summary, points, and tags are filled out ** Each team member should write 3-4 per project ** Make them small/bite-sized if possible--ideally doable in a week * Read [https://files.materovcompetition.org/2022/2022_MATE_ROV_Competition_Briefing_FINAL.pdf product demonstration and spec briefing] <br> Note: future competition info will be posted on the [https://materovcompetition.org/explorerspecs Explorer Specs page] === October 20th, 2021 - First New Member Meeting! === '''Goals''': * Set everyone up with all our accounts * Get mechanical members comfortable with the ROV * Start talking about our design process and mechanical designs '''Meeting summary''': * Shop tour (OCE 118) * Get everyone monday.com, google drive, google calendar, onshape, and wiki access * Took apart ROV * Everyone talked about what they liked and didn’t like about some part of it * Discussed potential solutions to the problems * Put ROV back together '''Do at home (after meeting)''': ''Note: optional items are not required, but strongly recommended.'' * Familiarize yourself with [https://uwrov.monday.com/boards/1820040986 current project ideas] and vote for the ones you are interested in - this will guide our meeting next week when we decide what to work on * Familiarize with last year’s competition ([https://youtu.be/KWNBOUqVIPQ challenge overview video]) and design ([https://drive.google.com/file/d/1pBVkW6_RF2LJdh3H6VVEtF_7T0Pu0uoD/view?usp=sharing 2021 technical documentation]) * Fill out the [https://www.when2meet.com/?13381598-gO5Hv Mechanical Office Hours when2meet] * ''Optional'': Get started with Onshape - follow the [https://uwrov.miraheze.org/wiki/Mechanical#How_do_I_get_started? guide on the Mechanical page] * ''Optional'': Bring a laptop to the next meeting if you can === DATE - TITLE === '''Goals''': * '''Meeting summary''': * '''Do at home (after meeting)''': * fae1d17d3836eb1809ad2111c680194b97464818 0 29 258 250 2021-12-05T00:34:07Z Alnis S 6 /* Requirements */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} b36b7f1947e02fdf6ee38fed32e401450b30dcd5 259 258 2021-12-05T00:37:37Z Alnis S 6 /* Structure */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | | | * | * |-style="vertical-align: top;" | Teddy | | | * | * |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | person | page | summary | advantages | disadvantages |} 29a5cd16a944d5871fb28c1782ab95bb7ad5362d 260 259 2021-12-05T00:39:08Z Alnis S 6 /* Design Concepts */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | | | * | * |-style="vertical-align: top;" | Teddy | | | * | * |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} 906af5444955b556d7fd792f0d854045b5162e1e 261 260 2021-12-05T00:41:57Z Alnis S 6 /* Design Concepts */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | | | * | * |-style="vertical-align: top;" | Teddy | | | * | * |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} 0e8ee3d60fff9b9d9c024ee52df9aec4dafd8857 269 261 2021-12-06T00:03:12Z Kjy5 27 Added Hercules-like design to concepts wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | [[Structure Concept 1: Basically Hercules]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | | | * | * |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} 26ead30452f65376f6fefe4ce3ab6a48dcbc3ea0 270 269 2021-12-08T23:32:36Z TeddyLautch 29 /* Structure */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | [[Structure Concept 1: Basically Hercules]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} ae6cfc8023134f03e141e373198faa5e95340518 280 270 2021-12-09T08:03:42Z Kjy5 27 Added link to in progress Ariana-I inspired design wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || * || * |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | * [[Structure Concept 1: Basically Hercules]] * In progress concept: [[Structure Concept 2: Ariana-I Inspired]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} 6f670362adda759bc77cfa63aff9a827d4c147d5 284 280 2021-12-16T01:12:49Z Alnis S 6 /* Requirements */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit * Propulsion brainstorming document from asynchronous work: https://docs.google.com/document/d/14a_t_G7UHeeSwe83yFSbcJ1G9XAckY_LQPh8CJ6UZoc/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping and regular operation * Risk of entanglement is mitigated || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting (with view of manipulator) * Housing the electronics || * Mounting for external sensors |-style="vertical-align: top;" | Propulsion || General requirements: * ROV is sufficiently maneuverable to complete competition tasks || * Easily detachable for easier transportation * Easy and intuitive to maneuver for human pilot * Does not require advanced software + electronics to be fully usable |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | * [[Structure Concept 1: Basically Hercules]] * In progress concept: [[Structure Concept 2: Ariana-I Inspired]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} 57e35be561f1b09b018523c934f7c4eb4833257c 287 284 2022-01-02T21:47:13Z Alnis S 6 /* Requirements */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit * Propulsion brainstorming document from asynchronous work: https://docs.google.com/document/d/14a_t_G7UHeeSwe83yFSbcJ1G9XAckY_LQPh8CJ6UZoc/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping and regular operation * Risk of entanglement is mitigated || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting: forward, down, and manipulator * Housing the electronics || * Mounting for external sensors * Nice to have camera views: rear, left, right * Lighting to improve colors at larger depths * Lasers for rangefinding * Single pressure hold makes it easier for electronics |-style="vertical-align: top;" | Propulsion || General requirements: * ROV is sufficiently maneuverable to complete competition tasks || * Easily detachable for easier transportation * Easy and intuitive to maneuver for human pilot * Does not require advanced software + electronics to be fully usable * Software team prefers 6 degrees of freedom |-style="vertical-align: top;" | Manipulator || * || * |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | * [[Structure Concept 1: Basically Hercules]] * In progress concept: [[Structure Concept 2: Ariana-I Inspired]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} 519b28108f7ee137c34e20ef18d95da6c152322b 288 287 2022-01-02T21:49:35Z Alnis S 6 wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit * Propulsion brainstorming document from asynchronous work: https://docs.google.com/document/d/14a_t_G7UHeeSwe83yFSbcJ1G9XAckY_LQPh8CJ6UZoc/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping and regular operation * Risk of entanglement is mitigated || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting: forward, down, and manipulator * Housing the electronics || * Mounting for external sensors * Nice to have camera views: rear, left, right * Lighting to improve colors at larger depths * Lasers for rangefinding * Single pressure hold makes it easier for electronics |-style="vertical-align: top;" | Propulsion || General requirements: * ROV is sufficiently maneuverable to complete competition tasks || * Easily detachable for easier transportation * Easy and intuitive to maneuver for human pilot * Does not require advanced software + electronics to be fully usable * Software team prefers 6 degrees of freedom |-style="vertical-align: top;" | Manipulator || * || * Ideally two manipulators to simultaneously do two tasks |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | * [[Structure Concept 1: Basically Hercules]] * In progress concept: [[Structure Concept 2: Ariana-I Inspired]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} b70c8563c6827d78f0c3c64a7d5576702182da1f 291 288 2022-01-03T03:53:03Z Alnis S 6 wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit * Propulsion brainstorming document from asynchronous work: https://docs.google.com/document/d/14a_t_G7UHeeSwe83yFSbcJ1G9XAckY_LQPh8CJ6UZoc/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping and regular operation * Risk of entanglement is mitigated || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting: forward, down, and manipulator * Housing the electronics || * Mounting for external sensors * Nice to have camera views: rear, left, right * Lighting to improve colors at larger depths * Lasers for rangefinding * Single pressure hold makes it easier for electronics |-style="vertical-align: top;" | Propulsion || General requirements: * ROV is sufficiently maneuverable to complete competition tasks || * Easily detachable for easier transportation * Easy and intuitive to maneuver for human pilot * Does not require advanced software + electronics to be fully usable * Software team prefers 6 degrees of freedom |-style="vertical-align: top;" | Manipulator || * || * Ideally two manipulators to simultaneously do two tasks |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | * [[Structure Concept 1: Basically Hercules]] * In progress concept: [[Structure Concept 2: Ariana-I Inspired]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} == 1.0 Iteration == January 2022 Key design decisions (made at [[Mechanical Meeting Notes#January 2nd, 2022 - Winter Quarter Kickoff|January 2nd, 2022 (Winter Quarter Kickoff)]] meeting: Approximate pressure hold size (similar, larger, smaller vs last year?) * Kenneth: smaller than last year main hull, one or two satellite ones for cameras * Anna: smaller separate ones for cameras * Ronan: same size, plus extra smaller ones for cameras * Teddy: same main size, adding waterproof cameras/little camera pressure holds * Cassandra: same main size, adding waterproof satellite cameras * Consensus: use the same size as last year, but develop secondary waterproof housings for cameras Propulsion: 6 DOF or not? * Maybe don’t need rolling rotation * Probably need to know competition/manipulation details * Better to have it than to not have it, but not if it adds difficulty * Maybe just moving manipulator is easier * Wait until later to see if it’s necessary * '''Consensus''': wait and see, but don’t cut off design directions Clear pressure hold or not? * Opaque with satellite cameras => More flexibility for cameras, less challenges with distortion of camera views * Maybe mineral oil for coolant/sealing? Is resin thermally conductive? * Would provide a thermal advantage to use metal Consensus: continue with large clear pressure hold, maybe go small and opaque pending how underwater cameras go Two manipulators or not? * Start with one as the main goal, but don’t go down a design path that prevents building a second one * Aim to have two manipulators in the second iteration Any other nice-to-haves we want to include? * None at the moment f0af7f96a33891b9126887cd3839d1eaa5820299 292 291 2022-01-03T03:54:55Z Alnis S 6 /* 1.0 Iteration */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit * Propulsion brainstorming document from asynchronous work: https://docs.google.com/document/d/14a_t_G7UHeeSwe83yFSbcJ1G9XAckY_LQPh8CJ6UZoc/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping and regular operation * Risk of entanglement is mitigated || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting: forward, down, and manipulator * Housing the electronics || * Mounting for external sensors * Nice to have camera views: rear, left, right * Lighting to improve colors at larger depths * Lasers for rangefinding * Single pressure hold makes it easier for electronics |-style="vertical-align: top;" | Propulsion || General requirements: * ROV is sufficiently maneuverable to complete competition tasks || * Easily detachable for easier transportation * Easy and intuitive to maneuver for human pilot * Does not require advanced software + electronics to be fully usable * Software team prefers 6 degrees of freedom |-style="vertical-align: top;" | Manipulator || * || * Ideally two manipulators to simultaneously do two tasks |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | * [[Structure Concept 1: Basically Hercules]] * In progress concept: [[Structure Concept 2: Ariana-I Inspired]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} == 1.0 Iteration == January 2022 Key design decisions (made at [[Mechanical Meeting Notes#January 2nd, 2022 - Winter Quarter Kickoff|January 2nd, 2022 (Winter Quarter Kickoff)]] meeting: Approximate pressure hold size (similar, larger, smaller vs last year?) * Kenneth: smaller than last year main hull, one or two satellite ones for cameras * Anna: smaller separate ones for cameras * Ronan: same size, plus extra smaller ones for cameras * Teddy: same main size, adding waterproof cameras/little camera pressure holds * Cassandra: same main size, adding waterproof satellite cameras * Consensus: use the same size as last year, but develop secondary waterproof housings for cameras Propulsion: 6 DOF or not? * Maybe don’t need rolling rotation * Probably need to know competition/manipulation details * Better to have it than to not have it, but not if it adds difficulty * Maybe just moving manipulator is easier * Wait until later to see if it’s necessary * '''Consensus''': wait and see, but don’t cut off design directions Clear pressure hold or not? * Opaque with satellite cameras => More flexibility for cameras, less challenges with distortion of camera views * Maybe mineral oil for coolant/sealing? Is resin thermally conductive? * Would provide a thermal advantage to use metal and space advantage to not have cameras inside * '''Consensus''': continue with large clear pressure hold, maybe go small and opaque pending how underwater cameras go Two manipulators or not? * Start with one as the main goal, but don’t go down a design path that prevents building a second one * Aim to have two manipulators in the second iteration * '''Consensus''': first iteration will target one manipulator, but likely target two for the second iteration Any other nice-to-haves we want to include? * None at the moment 386e5d5f029981c228c7fd6646af0b1fc4efb6c5 295 292 2022-01-03T04:08:54Z Alnis S 6 /* 1.0 Iteration */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit * Propulsion brainstorming document from asynchronous work: https://docs.google.com/document/d/14a_t_G7UHeeSwe83yFSbcJ1G9XAckY_LQPh8CJ6UZoc/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping and regular operation * Risk of entanglement is mitigated || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting: forward, down, and manipulator * Housing the electronics || * Mounting for external sensors * Nice to have camera views: rear, left, right * Lighting to improve colors at larger depths * Lasers for rangefinding * Single pressure hold makes it easier for electronics |-style="vertical-align: top;" | Propulsion || General requirements: * ROV is sufficiently maneuverable to complete competition tasks || * Easily detachable for easier transportation * Easy and intuitive to maneuver for human pilot * Does not require advanced software + electronics to be fully usable * Software team prefers 6 degrees of freedom |-style="vertical-align: top;" | Manipulator || * || * Ideally two manipulators to simultaneously do two tasks |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | * [[Structure Concept 1: Basically Hercules]] * In progress concept: [[Structure Concept 2: Ariana-I Inspired]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} == 1.0 Iteration == January 2022 === Key Design Decisions === Made at [[Mechanical Meeting Notes#January 2nd, 2022 - Winter Quarter Kickoff|January 2nd, 2022 (Winter Quarter Kickoff)]] meeting. Approximate pressure hold size (similar, larger, smaller vs last year?) * Kenneth: smaller than last year main hull, one or two satellite ones for cameras * Anna: smaller separate ones for cameras * Ronan: same size, plus extra smaller ones for cameras * Teddy: same main size, adding waterproof cameras/little camera pressure holds * Cassandra: same main size, adding waterproof satellite cameras * Consensus: use the same size as last year, but develop secondary waterproof housings for cameras Propulsion: 6 DOF or not? * Maybe don’t need rolling rotation * Probably need to know competition/manipulation details * Better to have it than to not have it, but not if it adds difficulty * Maybe just moving manipulator is easier * Wait until later to see if it’s necessary * '''Consensus''': Wait and see, but don’t cut off design directions. Nice to have, but not a problem if we don't have it. Clear pressure hold or not? * Opaque with satellite cameras => More flexibility for cameras, less challenges with distortion of camera views * Maybe mineral oil for coolant/sealing? Is resin thermally conductive? * Would provide a thermal advantage to use metal and space advantage to not have cameras inside * '''Consensus''': continue with large clear pressure hold, maybe go small and opaque pending how underwater cameras go Two manipulators or not? * Start with one as the main goal, but don’t go down a design path that prevents building a second one * Aim to have two manipulators in the second iteration * '''Consensus''': first iteration will target one manipulator, but likely target two for the second iteration Any other nice-to-haves we want to include? * None at the moment === ROV Core === Group design guidance: * Good set-down-ability: a handle and rubber feet * 6 DOF propulsion without funny motor angles like [[Structure Concept 2: Ariana-I Inspired|Ariana-I design concept]] * Avoid large solid/flat parts for easier movement through water * Ensure room on the bottom for a camera and/or manipulator * Ensure easy redistribution/balancing of weight * Be mindful of tether connection ** Prevent thruster interference ** Ensure connection doesn't make ROV hard to balance * Use a build system (C channel, X rail, etc.) ** Improves ease of adjustability and iteration ** If using X rail, ensure some way to keep positions accurate. ** Easy to modify design and take apart for shipping * Top-down external camera view to see manipulator ** Requires a waterproof camera/secondary enclosure ** Improves pilot awareness and ease of manipulator positioning === Manipulator === === Float === === Miscellaneous === efc03ad42dacba59e6eab9804b4f0e222352ba45 298 295 2022-01-03T04:31:59Z Alnis S 6 /* 1.0 Iteration */ wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit * Propulsion brainstorming document from asynchronous work: https://docs.google.com/document/d/14a_t_G7UHeeSwe83yFSbcJ1G9XAckY_LQPh8CJ6UZoc/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping and regular operation * Risk of entanglement is mitigated || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting: forward, down, and manipulator * Housing the electronics || * Mounting for external sensors * Nice to have camera views: rear, left, right * Lighting to improve colors at larger depths * Lasers for rangefinding * Single pressure hold makes it easier for electronics |-style="vertical-align: top;" | Propulsion || General requirements: * ROV is sufficiently maneuverable to complete competition tasks || * Easily detachable for easier transportation * Easy and intuitive to maneuver for human pilot * Does not require advanced software + electronics to be fully usable * Software team prefers 6 degrees of freedom |-style="vertical-align: top;" | Manipulator || * || * Ideally two manipulators to simultaneously do two tasks |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | * [[Structure Concept 1: Basically Hercules]] * In progress concept: [[Structure Concept 2: Ariana-I Inspired]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} == 1.0 Iteration == January 2022 === Key Design Decisions === Made at [[Mechanical Meeting Notes#January 2nd, 2022 - Winter Quarter Kickoff|January 2nd, 2022 (Winter Quarter Kickoff)]] meeting. Approximate pressure hold size (similar, larger, smaller vs last year?) * Kenneth: smaller than last year main hull, one or two satellite ones for cameras * Anna: smaller separate ones for cameras * Ronan: same size, plus extra smaller ones for cameras * Teddy: same main size, adding waterproof cameras/little camera pressure holds * Cassandra: same main size, adding waterproof satellite cameras * Consensus: use the same size as last year, but develop secondary waterproof housings for cameras Propulsion: 6 DOF or not? * Maybe don’t need rolling rotation * Probably need to know competition/manipulation details * Better to have it than to not have it, but not if it adds difficulty * Maybe just moving manipulator is easier * Wait until later to see if it’s necessary * '''Consensus''': Wait and see, but don’t cut off design directions. Nice to have, but not a problem if we don't have it. Clear pressure hold or not? * Opaque with satellite cameras => More flexibility for cameras, less challenges with distortion of camera views * Maybe mineral oil for coolant/sealing? Is resin thermally conductive? * Would provide a thermal advantage to use metal and space advantage to not have cameras inside * '''Consensus''': continue with large clear pressure hold, maybe go small and opaque pending how underwater cameras go Two manipulators or not? * Start with one as the main goal, but don’t go down a design path that prevents building a second one * Aim to have two manipulators in the second iteration * '''Consensus''': first iteration will target one manipulator, but likely target two for the second iteration Any other nice-to-haves we want to include? * None at the moment === ROV Core === Group design guidance: * Good set-down-ability: a handle and rubber feet * 6 DOF propulsion without funny motor angles like [[Structure Concept 2: Ariana-I Inspired|Ariana-I design concept]] * Avoid large solid/flat parts for easier movement through water * Ensure room on the bottom for a camera and/or manipulator * Ensure easy redistribution/balancing of weight * Be mindful of tether connection ** Prevent thruster interference ** Ensure connection doesn't make ROV hard to balance * Use a build system (C channel, X rail, etc.) ** Improves ease of adjustability and iteration ** If using X rail, ensure some way to keep positions accurate. ** Easy to modify design and take apart for shipping * Top-down external camera view to see manipulator ** Requires a waterproof camera/secondary enclosure ** Improves pilot awareness and ease of manipulator positioning Recommended timeline: * Week of Jan 3: planning, research, preliminary design * Week of Jan 10: detailed prototype design work (CAD) * Week of Jan 17: fabrication, procurement, and assembly * Week of Jan 24: testing and refinement * Week of Jan 31: integration! === Manipulator === Recommended timeline: * Week of Jan 3: planning, research, preliminary design to test * Week of Jan 10: hack together a prototype and test it * Week of Jan 17: detailed prototype design work (CAD) * Week of Jan 24: fabrication, procurement, and assembly, hopefully testing and refinement * Week of Jan 31: integration! === Float === Recommended timeline: * Week of Jan 3: planning, research, preliminary design * Week of Jan 10: detailed prototype design work (CAD) * Week of Jan 17: detailed prototype design work (CAD) * Week of Jan 24: fabrication, procurement, and assembly * Week of Jan 31: fabrication, procurement, and assembly, plus maybe testing! === Miscellaneous === Recommended timeline: * Week of Jan 3: planning, research, block diagram of surface station + basic planning, proof of concept simulation import * Week of Jan 10: refine simulation import process to work with more complex model, more detailed surface station design work * Week of Jan 17: work with ROV Core to import existing frame/propulsion to simulation, review and refine surface station with software & electrical * Week of Jan 24: test code with simulated ROV, fabrication, procurement, and assembly of surface station * Week of Jan 31: test code with simulated ROV, fabrication, procurement, and assembly of surface station 078c453326d610da604753f0841ca3320d4c21ca 0 34 262 2021-12-05T23:02:14Z Kjy5 27 Created page with "Concept by Kenneth Yang for ROV22 structural designs; requirements found here: [[ROV22_Design_Overview]] Summary goes here == Overview == The description of the proposed so..." wikitext text/x-wiki Concept by Kenneth Yang for ROV22 structural designs; requirements found here: [[ROV22_Design_Overview]] Summary goes here == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == 4a30002c5fb326b9ed4b25ca5a4a772f5e1b7306 264 262 2021-12-05T23:15:52Z Kjy5 27 Added summary and diagram (as thumbnail) wikitext text/x-wiki Concept by Kenneth Yang for ROV22 structural designs; requirements found here: [[ROV22_Design_Overview|ROV22 Design Overview]] Taking great inspiration from the first few results that come up when googling "ROV", most designs look a lot like this. Specifically, the ROV Hercules on the Nautilus exploration program looks like this. == Overview == [[File:Hercules-like design.png|thumb|right|alt=Diagrammed sketch of an ROV design heavily inspired by the ROV Hercules from the Nautilus exploration program|Diagrammed sketch of an ROV design heavily inspired by the ROV Hercules from the Nautilus exploration program]] This design opens up more room in the bow of the ROV to allow for more manipulator articulation/working space while also introducing a new camera angle to view things with. With a simple frame cross-section, the design should be simple to manufacture while also allowing for plenty of customizability to add mounting points. This design also puts an emphasis on having the tether system be attached to the roof of the ROV and most of the mass lower in the frame, giving the ROV better balance and also removing the tilting problem with the tether (apparently the ROV had a tendency to tilt forward when the tether was attached directly to the stern). == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == 94a11f795fd86185c747b6db312c628ebaffce46 265 264 2021-12-05T23:44:43Z Kjy5 27 Wrote in rest of the description. wikitext text/x-wiki Concept by Kenneth Yang for ROV22 structural designs; requirements found here: [[ROV22_Design_Overview|ROV22 Design Overview]] Taking great inspiration from the first few results that come up when googling "ROV", most designs look a lot like this. Specifically, the ROV Hercules on the Nautilus exploration program looks like this. == Overview == [[File:Hercules-like design.png|thumb|right|alt=Diagrammed sketch of an ROV design heavily inspired by the ROV Hercules from the Nautilus exploration program|Diagrammed sketch of an ROV design heavily inspired by the ROV Hercules from the Nautilus exploration program]] This design opens up more room in the bow of the ROV to allow for more manipulator articulation/working space while also introducing a new camera angle to view things with. With a simple frame cross-section, the design should be simple to manufacture while also allowing for plenty of customizability to add mounting points. This design also puts an emphasis on having the tether system be attached to the roof of the ROV and most of the mass lower in the frame, giving the ROV better balance and also removing the tilting problem with the tether (apparently the ROV had a tendency to tilt forward when the tether was attached directly to the stern). == Advantages == === In general === This is a tried and validated frame design/concept as the ROV Hercules employs a similar design. === Versus previous UWROV designs === The main difference with this design is that by making the ROV taller and moving the manipulator out from the ROV, we free up a lot of room for it to work and also make it easier to see what is happening. === Versus other industry/commercial/published options === Well... this is actually one of the most common designs found out on the internet. The idea has been proven to work, now we get the opportunity to make an implementation-specific to our pressure hull design. One key difference from other designs is that the roof of this design is actually hollow/empty meaning its center of mass is lower (by the manipulator). == Disadvantages == === In general === In the current diagram, I have two pressure hold: one for the main electronics and a second one specifically for the camera looking down at the manipulator. A second pressure hold may not be necessary, but there needs to be a second housing for a camera. This design though also puts the main camera more or less directly behind the manipulator meaning the main camera can also be used to see what is going on. === Versus previous UWROV designs === The roof-mounted tether port would need to connect with the existing stern-mounted tether port on the current pressure hold. So either a new pressure hold will have to be created, or extra cabling will have to be employed. === Versus other industry/commercial/published options === Again most of the electronics will be held in the pressure hold which is located lower than the tether. Conventionally, the computer is held in the roof while motors, power supplies, and other items are separated out. Since we don't have that much equipment most of the items will be contained within the pressure hold and not separated out into electronics and motors. == See also == [https://nautiluslive.org/tech/rov-hercules#:~:text=ROV%20Hercules%20is%20at%20the,and%20chemistry%20of%20the%20ocean.&text=A%20pair%20of%20manipulator%20arms,geological%20samples%20with%20precise%20dexterity.| ROV Hercules by Nautilus] 824c421e7431ae73204416544d234a6671aa2185 268 265 2021-12-05T23:59:25Z Kjy5 27 Changed initial link URL wikitext text/x-wiki Concept by Kenneth Yang for ROV22 structural designs; requirements found here: [[ROV22 Design Overview]] Taking great inspiration from the first few results that come up when googling "ROV", most designs look a lot like this. Specifically, the ROV Hercules on the Nautilus exploration program looks like this. == Overview == [[File:Hercules-like design.png|thumb|right|alt=Diagrammed sketch of an ROV design heavily inspired by the ROV Hercules from the Nautilus exploration program|Diagrammed sketch of an ROV design heavily inspired by the ROV Hercules from the Nautilus exploration program]] This design opens up more room in the bow of the ROV to allow for more manipulator articulation/working space while also introducing a new camera angle to view things with. With a simple frame cross-section, the design should be simple to manufacture while also allowing for plenty of customizability to add mounting points. This design also puts an emphasis on having the tether system be attached to the roof of the ROV and most of the mass lower in the frame, giving the ROV better balance and also removing the tilting problem with the tether (apparently the ROV had a tendency to tilt forward when the tether was attached directly to the stern). == Advantages == === In general === This is a tried and validated frame design/concept as the ROV Hercules employs a similar design. === Versus previous UWROV designs === The main difference with this design is that by making the ROV taller and moving the manipulator out from the ROV, we free up a lot of room for it to work and also make it easier to see what is happening. === Versus other industry/commercial/published options === Well... this is actually one of the most common designs found out on the internet. The idea has been proven to work, now we get the opportunity to make an implementation-specific to our pressure hull design. One key difference from other designs is that the roof of this design is actually hollow/empty meaning its center of mass is lower (by the manipulator). == Disadvantages == === In general === In the current diagram, I have two pressure hold: one for the main electronics and a second one specifically for the camera looking down at the manipulator. A second pressure hold may not be necessary, but there needs to be a second housing for a camera. This design though also puts the main camera more or less directly behind the manipulator meaning the main camera can also be used to see what is going on. === Versus previous UWROV designs === The roof-mounted tether port would need to connect with the existing stern-mounted tether port on the current pressure hold. So either a new pressure hold will have to be created, or extra cabling will have to be employed. === Versus other industry/commercial/published options === Again most of the electronics will be held in the pressure hold which is located lower than the tether. Conventionally, the computer is held in the roof while motors, power supplies, and other items are separated out. Since we don't have that much equipment most of the items will be contained within the pressure hold and not separated out into electronics and motors. == See also == [https://nautiluslive.org/tech/rov-hercules#:~:text=ROV%20Hercules%20is%20at%20the,and%20chemistry%20of%20the%20ocean.&text=A%20pair%20of%20manipulator%20arms,geological%20samples%20with%20precise%20dexterity.| ROV Hercules by Nautilus] 787ed1df926d35a63517b6bf1e6b9abd02f3745a 281 268 2021-12-09T08:03:50Z Kjy5 27 fixed URL wikitext text/x-wiki Concept by Kenneth Yang for ROV22 structural designs; requirements found here: [[ROV22 Design Overview]] Taking great inspiration from the first few results that come up when googling "ROV", most designs look a lot like this. Specifically, the ROV Hercules on the Nautilus exploration program looks like this. == Overview == [[File:Hercules-like design.png|thumb|right|alt=Diagrammed sketch of an ROV design heavily inspired by the ROV Hercules from the Nautilus exploration program|Diagrammed sketch of an ROV design heavily inspired by the ROV Hercules from the Nautilus exploration program]] This design opens up more room in the bow of the ROV to allow for more manipulator articulation/working space while also introducing a new camera angle to view things with. With a simple frame cross-section, the design should be simple to manufacture while also allowing for plenty of customizability to add mounting points. This design also puts an emphasis on having the tether system be attached to the roof of the ROV and most of the mass lower in the frame, giving the ROV better balance and also removing the tilting problem with the tether (apparently the ROV had a tendency to tilt forward when the tether was attached directly to the stern). == Advantages == === In general === This is a tried and validated frame design/concept as the ROV Hercules employs a similar design. === Versus previous UWROV designs === The main difference with this design is that by making the ROV taller and moving the manipulator out from the ROV, we free up a lot of room for it to work and also make it easier to see what is happening. === Versus other industry/commercial/published options === Well... this is actually one of the most common designs found out on the internet. The idea has been proven to work, now we get the opportunity to make an implementation-specific to our pressure hull design. One key difference from other designs is that the roof of this design is actually hollow/empty meaning its center of mass is lower (by the manipulator). == Disadvantages == === In general === In the current diagram, I have two pressure hold: one for the main electronics and a second one specifically for the camera looking down at the manipulator. A second pressure hold may not be necessary, but there needs to be a second housing for a camera. This design though also puts the main camera more or less directly behind the manipulator meaning the main camera can also be used to see what is going on. === Versus previous UWROV designs === The roof-mounted tether port would need to connect with the existing stern-mounted tether port on the current pressure hold. So either a new pressure hold will have to be created, or extra cabling will have to be employed. === Versus other industry/commercial/published options === Again most of the electronics will be held in the pressure hold which is located lower than the tether. Conventionally, the computer is held in the roof while motors, power supplies, and other items are separated out. Since we don't have that much equipment most of the items will be contained within the pressure hold and not separated out into electronics and motors. == See also == [https://nautiluslive.org/tech/rov-hercules#:~:text=ROV%20Hercules%20is%20at%20the,and%20chemistry%20of%20the%20ocean.&text=A%20pair%20of%20manipulator%20arms,geological%20samples%20with%20precise%20dexterity. ROV Hercules by Nautilus] 27816c4092d79e69de3754b217641a18e2413058 6 35 263 2021-12-05T23:09:11Z Kjy5 27 wikitext text/x-wiki Diagrammed sketch of an ROV design heavily inspired by the ROV Hercules from the Nautilus exploration program b8764e4e55a10d86ecdb1df513d9ff356076f44a 0 36 271 2021-12-08T23:34:48Z TeddyLautch 29 Created page with "Concept by Person Name for Project; requirements found here: link to wiki page Summary goes here == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other indus..." wikitext text/x-wiki Concept by Person Name for Project; requirements found here: link to wiki page Summary goes here == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == 3537500236231d3d51fbbe458f17545e6b25b0f2 272 271 2021-12-08T23:38:02Z TeddyLautch 29 wikitext text/x-wiki Concept by [[User:TeddyLautch|Teddy Lautch]] for ROV22]]; requirements found here: link to wiki page Summary goes here == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == b84921bce6028038a5aa2e9287fd99c569389ea7 274 272 2021-12-08T23:40:42Z TeddyLautch 29 wikitext text/x-wiki Concept by [[User:TeddyLautch|Teddy Lautch]] for ROV22]]; [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] Use modular aluminum x-rails or similar parts to create a frame that's easy to work with. == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == 480a889791cec054fb10e2f47e6442b7af6c6fb7 275 274 2021-12-08T23:41:00Z TeddyLautch 29 wikitext text/x-wiki Concept by [[User:TeddyLautch|Teddy Lautch]] for [[ROV22]]; [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] Use modular aluminum x-rails or similar parts to create a frame that's easy to work with. == Overview == The description of the proposed solution goes here. Images, links to models, links to references, etc. are recommended. == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == 4421f326722c51a62a46fd589771b108abb74266 276 275 2021-12-08T23:54:23Z TeddyLautch 29 wikitext text/x-wiki Concept by [[User:TeddyLautch|Teddy Lautch]] for [[ROV22]]; requirements found here: [[ROV22 Design Overview#Requirements|ROV22 Design Overview]] Use modular aluminum x-rails or similar parts to create a frame that's easy to work with. == Overview == By using extruded aluminum x-rails, we are able to easily make custom length parts, and to slide new parts and prototypes in and out of the frame. This makes it easy to manufacture, construct, and iterate the ROV. An example of this design from Jesuit Rovotics, the #1 in person team for the previous year: [https://files.materovcompetition.org/TechReportArchives/2021/JesuitHighSchool_Rovotics_Technical%20Documentation_2021.pdf Jesuit Rovotics Technical Documentation] == Advantages == === In general === * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining === Versus previous UWROV designs === * Previous ROVs had structural issues that could have easily been solved with adding additional modules (i.e. manipulator not being supported) * Rather than adjusting ballast with messy zipties, can easily change the position and the type of ballast by sliding to achieve stability * Easy to mount new parts if something needs to be changed out === Versus other industry/commercial/published options === == Disadvantages == === In general === * Not quite as rigid in general * Need to purchase new parts * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates === Versus previous UWROV designs === * Not quite as flexible as not everything is custom manufactured, although custom parts and plates can still be attached. === Versus other industry/commercial/published options === == See also == 6ea4e23b396d300dac04fdd032251c689b1db8a4 2 37 273 2021-12-08T23:39:26Z TeddyLautch 29 Created page with "Hi, I'm Teddy" wikitext text/x-wiki Hi, I'm Teddy d6ca768310265eab7ed09b5e339ec2042fd5671c 6 38 277 2021-12-09T07:55:23Z Kjy5 27 wikitext text/x-wiki A new chassis focused on ROV mobility and giving a lot of room up at the bow from electronics and a manipulator 678b191fbb51bac8012de5d74854e61b339e3a1b 6 39 278 2021-12-09T07:57:06Z Kjy5 27 wikitext text/x-wiki CAD drawing of the Ariana-I ROV f999c3bd9b55283f894dd098f84225cd0df43545 0 40 279 2021-12-09T08:02:20Z Kjy5 27 Introduce the Ariana-I inspired design. Page in progress wikitext text/x-wiki Concept by Kenneth Yang for ROV22 structural designs; requirements found here: [[ROV22 Design Overview]] *NOTE: PAGE IN PROGRESS* This is a pretty dramatic redesign mostly focused on the idea of ROV mobility and opening a large amount of free space for electronics up at the front. This design was inspired by a picture of the ROV Ariana-I. == Overview == [[File:Ariana-I inspired design.png|thumb|right|alt=Sketch of new design|An Ariana-I inspired design]] [[File:Ariana-I design.png|thumb|right|ROV Ariana-I, from https://asmedigitalcollection.asme.org/IMECE/proceedings/IMECE2011/54938/1295/358650]] Found this image of the Ariana-I ROV design from [https://asmedigitalcollection.asme.org/IMECE/proceedings/IMECE2011/54938/1295/358650 this book] and liked the idea of motors mounted inside the chassis and facing in the 3 axes of movement. I adapted this design to allow for control for roll, pitch, lateral movement, and forward/backward movement. This design also gives us a ton of room up front to put electronics, cameras, and a manipulator. The structure will be slightly more complex to design but should fit together in a simple box-like fashion. == Advantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == Disadvantages == === In general === === Versus previous UWROV designs === === Versus other industry/commercial/published options === == See also == 6a38d2c1f098145962e81cd07e774786741b0c31 6 41 282 2021-12-13T21:15:12Z Alnis S 6 wikitext text/x-wiki https://cad.onshape.com/documents/9856065b8c774e73d3ab0c56/w/c43296056d7aa7361ffe9425/e/587c823c236049b60b726a12 f6be3c5b2db3a16091936bdccdfeafff7c5608c6 0 42 300 2022-01-18T02:16:16Z Alnis S 6 Created page with "{|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]||Tips and tricks for designing 3D printed parts||2021-07-23 |- |}" wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]||Tips and tricks for designing 3D printed parts||2021-07-23 |- |} 977e048f65c1c7090698dacd0403164573f4191e 0 42 301 300 2022-01-18T02:16:30Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]||Tips and tricks for designing 3D printed parts||2022-01-17 |- |} ace1e38097ee1c795a2a643bc8474907c5697c33 303 301 2022-01-18T02:31:31Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |} f9e059235660c92d849b95787b3cf8270ed83a03 316 303 2022-01-23T20:38:06Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |} 02493f9d68c3986041aee4b2ccaf4a8a23ef95ad 317 316 2022-01-23T20:50:14Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |[[Design for Sheet Metal]]: Introduction||A quick introduction to designing parts that can be made from cut and folded sheet metal||Weekend of Jan 29 & 30 |- |} af78cb633bbcf2e5715e7a699f7a535431c86b10 318 317 2022-01-23T22:56:02Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |[[Design for 3D Printing]]: CAD Tips||Tips and tricks for effectively using CAD for 3D printed parts||Weekend of Jan 29 & 30 |- |[[Design for Sheet Metal]]: Introduction||A quick introduction to designing parts that can be made from cut and folded sheet metal||Weekend of Feb 5 & 6 |- |} 2ecc081365246dfb60def04ef46af575ffd66c61 347 318 2022-03-06T21:48:12Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |[[Design for 3D Printing]]: CAD Tips||Tips and tricks for effectively using CAD for 3D printed parts||Weekend of Jan 29 & 30 |- |[[Design for Sheet Metal]]: Introduction||A quick introduction to designing parts that can be made from cut and folded sheet metal||Weekend of Feb 5 & 6 |- |[http://507movements.com/ 507 Mechanical Movements]|Hundreds of interesting mechanisms and contraptions. Post one that seems relevant to ROV in #me-learning!|2022-02-20 |- |[https://vimeo.com/679543161 MATE flythrough video]|Animated overview of this year's competition|2022-02-27 |- |[https://youtu.be/l2nNmENmMdk How To Make Prototypes: Jeremy Fielding]|A video on the process of prototyping robotic systems. What is one takeaway/quotable quote that you found useful or inspiring?|2022-03-06 |- |} 452ef7d930a4970d6bd889f942ce3c332b1cb652 348 347 2022-03-07T02:19:45Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |[[Design for 3D Printing]]: CAD Tips||Tips and tricks for effectively using CAD for 3D printed parts||Weekend of Jan 29 & 30 |- |[[Design for Sheet Metal]]: Introduction||A quick introduction to designing parts that can be made from cut and folded sheet metal||Weekend of Feb 5 & 6 |- |[http://507movements.com/ 507 Mechanical Movements]||Hundreds of interesting mechanisms and contraptions. Post one that seems relevant to ROV in #me-learning!||2022-02-20 |- |[https://vimeo.com/679543161 MATE flythrough video]||Animated overview of this year's competition||2022-02-27 |- |[https://youtu.be/l2nNmENmMdk How To Make Prototypes: Jeremy Fielding]||A video on the process of prototyping robotic systems. What is one takeaway/quotable quote that you found useful or inspiring?||2022-03-06 |- |} 0e3171616f5424158cf2cc67351ff205b1091aa9 349 348 2022-03-29T06:59:22Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |[[Design for 3D Printing]]: CAD Tips||Tips and tricks for effectively using CAD for 3D printed parts||Weekend of Jan 29 & 30 |- |[[Design for Sheet Metal]]: Introduction||A quick introduction to designing parts that can be made from cut and folded sheet metal||Weekend of Feb 5 & 6 |- |[http://507movements.com/ 507 Mechanical Movements]||Hundreds of interesting mechanisms and contraptions. Post one that seems relevant to ROV in #me-learning!||2022-02-20 |- |[https://vimeo.com/679543161 MATE flythrough video]||Animated overview of this year's competition||2022-02-27 |- |[https://youtu.be/l2nNmENmMdk How To Make Prototypes: Jeremy Fielding]||A video on the process of prototyping robotic systems. What is one takeaway/quotable quote that you found useful or inspiring?||2022-03-06 |- |[https://youtu.be/fmXFWi-WfyU Rotational motion]<br>[https://youtu.be/b-HZ1SZPaQw Torque]<br>[https://youtu.be/9cbF9A6eQNA Statics crash course]||Three short (~10 min) videos that provide a great intuitive grounding in mechanical analysis.<br>No need to take notes or remember formulas---just try to absorb the general concepts and keywords.||2022-03-28 |- |} 11a9948ed72b3843e3e2d5ee62f2fcfc1ea02de7 350 349 2022-04-10T07:37:58Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |[[Design for 3D Printing]]: CAD Tips||Tips and tricks for effectively using CAD for 3D printed parts||Weekend of Jan 29 & 30 |- |[[Design for Sheet Metal]]: Introduction||A quick introduction to designing parts that can be made from cut and folded sheet metal||Weekend of Feb 5 & 6 |- |[http://507movements.com/ 507 Mechanical Movements]||Hundreds of interesting mechanisms and contraptions. Post one that seems relevant to ROV in #me-learning!||2022-02-20 |- |[https://vimeo.com/679543161 MATE flythrough video]||Animated overview of this year's competition||2022-02-27 |- |[https://youtu.be/l2nNmENmMdk How To Make Prototypes: Jeremy Fielding]||A video on the process of prototyping robotic systems. What is one takeaway/quotable quote that you found useful or inspiring?||2022-03-06 |- |[https://youtu.be/fmXFWi-WfyU Rotational motion]<br>[https://youtu.be/b-HZ1SZPaQw Torque]<br>[https://youtu.be/9cbF9A6eQNA Statics crash course]||Three short (~10 min) videos that provide a great intuitive grounding in mechanical analysis.<br>No need to take notes or remember formulas---just try to absorb the general concepts and keywords.||2022-03-28 |- |[https://youtu.be/UYv1pQnQvP4?t=167 Motors and Speed Controllers (can skip to 2:47)]<br>[https://youtu.be/enFKeOcjreE Electronics]||Two 15-minute videos from Battlebots Team Witch Doctor about combat robotics electronics. We're not building a combat robot and the videos are in large part about putting together a kit, but the parts about ESCs and motors are relevant! Note: these videos discuss brushed DC motors, while we use brushless motors. The wiring overall is similar, but not quite the same. Next week will have info about brushless motors! |- |} 9cb164533fe7f65ca00a35cc84ffdeb9b1e5646c 0 43 302 2022-01-18T02:30:54Z Alnis S 6 Created page with "== FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality i..." wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === === Preventing Print Failures === === Improving Print Quality === 50aca92341fb0d33175e1e96cefc429b6071c8ac 305 302 2022-01-18T04:18:23Z Alnis S 6 /* FDM Printer Tips */ wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === 3D printers produce parts relatively quickly but have certain quirks for how big they end up printing stuff. Most of these can be predicted and worked around by modifying the design or print settings, but it is important to be aware of common pitfalls and how to fix them. ==== Elephant Foot ==== For the first few layers of a print, to improve adhesion and prevent peeling/warping, the nozzle is often slightly closer to the plate than the thickness of the first layer. This results in material being squished out, resulting in a widening of the first few layers. This can cause issues with parts not fitting into tight spaces, parts not looking very good, and not having flat sides when necessary. Additionally, prints may end up slightly shorter than intended. To remedy this, there are a few options: * Apply a small (~0.4 to 0.8 mm) chamfer to the bottom of a part * Print with a raft if chamfers are not an option * Sand down edges (tedious for large parts) * Print part in such an orientation that elephant's foot doesn't matter * Fiddle with 3D printer settings until it prints right * If the part is too short, but the elephant foot doesn't really matter, make it taller in CAD (e.g. a spacer) [[File:Elephant-foot.jpg|thumb|Cube on the right has elephant foot]] ==== Hole Sizing (and general print sizing) ==== In general, 3d prints tend to be slightly wider horizontally than how they are designed in CAD. Part of this is due to printer filament squishing out, and part of it is because layers are not perfectly even/lined up, resulting in some higher bumps and uneven areas. As a result, holes printed using FDM printers usually end up a bit too small, and pegs/shafts end up a bit too big. There are two main solutions: * Offset faces "inward" by some amount in CAD. Some generally applicable values: ** 0.1 mm results in a tight fit (hammer/press required) ** 0.2 mm results in a fit that can be assembled by hand, but can't be relied on to freely rotate ** 0.3-0.4+ mm results in a fit that will freely rotate and move around * Accept that things might print too big and use sandpaper or a drill to fix it ** This often happens when the CAD is not updated ahead of time! === Preventing Print Failures === It is easy to accidentally produce spaghetti (or perhaps modern art, depending on your perspective) using an FDM printer. This happens when the print detaches from the print bed and slides around as material is added, resulting in fascinating results. ==== Design Issues ==== Spindly, narrow, and tall parts are generally more challenging to print successfully than low, wide, and boring parts. * If a design has large overhangs, try reorienting the part and/or splitting it into multiple easier to print parts * If a design has a first layer with little surface area, consider adding a brim or raft in the slicer * If a design requires long, narrow sheets or cylinders, consider changing the material to sheet metal or metal shafts that are later assembled ==== Print Setup Issues ==== Physical causes: * Print bed surface adhesion ** Wipe down with isopropyl alcohol on a paper towel to improve adhesion ** Blue masking tape on the print bed can also help adhesion * Print bed leveling ** Uneven/warped print beds can cause print failures ** Not leveling a print bed carefully can cause some areas to be too far from the nozzle to adhere correctly Slicing causes: * Part orientation issues: rotated to be tall/narrow instead of low/wide * Temperature set too low for print bed or nozzle * Not enough supports added for overhanging areas * Not using a brim or raft for challenging/detailed first layers === Improving Print Quality === 246e5122d23c2d063276cf0a27ea29cab7344f69 306 305 2022-01-18T04:31:00Z Alnis S 6 /* FDM Printer Tips */ wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === 3D printers produce parts relatively quickly but have certain quirks for how big they end up printing stuff. Most of these can be predicted and worked around by modifying the design or print settings, but it is important to be aware of common pitfalls and how to fix them. ==== Elephant Foot ==== For the first few layers of a print, to improve adhesion and prevent peeling/warping, the nozzle is often slightly closer to the plate than the thickness of the first layer. This results in material being squished out, resulting in a widening of the first few layers. This can cause issues with parts not fitting into tight spaces, parts not looking very good, and not having flat sides when necessary. Additionally, prints may end up slightly shorter than intended. To remedy this, there are a few options: * Apply a small (~0.4 to 0.8 mm) chamfer to the bottom of a part * Print with a raft if chamfers are not an option * Sand down edges (tedious for large parts) * Print part in such an orientation that elephant's foot doesn't matter * Fiddle with 3D printer settings until it prints right * If the part is too short, but the elephant foot doesn't really matter, make it taller in CAD (e.g. a spacer) [[File:Elephant-foot.jpg|thumb|Cube on the right has elephant foot]] ==== Hole Sizing (and general print sizing) ==== In general, 3d prints tend to be slightly wider horizontally than how they are designed in CAD. Part of this is due to printer filament squishing out, and part of it is because layers are not perfectly even/lined up, resulting in some higher bumps and uneven areas. As a result, holes printed using FDM printers usually end up a bit too small, and pegs/shafts end up a bit too big. There are two main solutions: * Offset faces "inward" by some amount in CAD. Some generally applicable values: ** 0.1 mm results in a tight fit (hammer/press required) ** 0.2 mm results in a fit that can be assembled by hand, but can't be relied on to freely rotate ** 0.3-0.4+ mm results in a fit that will freely rotate and move around * Accept that things might print too big and use sandpaper or a drill to fix it ** This often happens when the CAD is not updated ahead of time! ==== Warping ==== For prints with large, plate-like surfaces (e.g. boxes, plates, large components in general, etc.), corners may have a tendency to come off of the print bed. While this is more of a function of the quality of a 3D printer than anything else, there are a few remedies: * Change the design to another material/process if the design allows it, or split it into multiple smaller parts * Add fillets to corners on the face that is the first layer (sharp corners tend to warp more) * Add a brim or a raft to improve adhesion and follow the steps from the "Preventing Print Failures" section * Increase the nozzle temperature for the first layer, as well as the print bed temperature overall (this may cause drooping or increased elephant foot) === Preventing Print Failures === It is easy to accidentally produce spaghetti (or perhaps modern art, depending on your perspective) using an FDM printer. This happens when the print detaches from the print bed and slides around as material is added, resulting in fascinating results. ==== Design Issues ==== Spindly, narrow, and tall parts are generally more challenging to print successfully than low, wide, and boring parts. * If a design has large overhangs, try reorienting the part and/or splitting it into multiple easier to print parts * If a design has a first layer with little surface area, consider adding a brim or raft in the slicer * If a design requires long, narrow sheets or cylinders, consider changing the material to sheet metal or metal shafts that are later assembled ==== Print Setup Issues ==== Physical causes: * Print bed surface adhesion ** Wipe down with isopropyl alcohol on a paper towel to improve adhesion ** Blue masking tape on the print bed can also help adhesion * Print bed leveling ** Uneven/warped print beds can cause print failures ** Not leveling a print bed carefully can cause some areas to be too far from the nozzle to adhere correctly Slicing causes: * Part orientation issues: rotated to be tall/narrow instead of low/wide * Temperature set too low for print bed or nozzle * Not enough supports added for overhanging areas * Not using a brim or raft for challenging/detailed first layers === Improving Print Quality === FDM 3D printers 4cb59a25363ec57caac1ce79923c6e0e2c44a676 307 306 2022-01-18T05:19:54Z Alnis S 6 wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === 3D printers produce parts relatively quickly but have certain quirks for how big they end up printing stuff. Most of these can be predicted and worked around by modifying the design or print settings, but it is important to be aware of common pitfalls and how to fix them. ==== Elephant Foot ==== For the first few layers of a print, to improve adhesion and prevent peeling/warping, the nozzle is often slightly closer to the plate than the thickness of the first layer. This results in material being squished out, resulting in a widening of the first few layers. This can cause issues with parts not fitting into tight spaces, parts not looking very good, and not having flat sides when necessary. Additionally, prints may end up slightly shorter than intended. To remedy this, there are a few options: * Apply a small (~0.4 to 0.8 mm) chamfer to the bottom of a part * Print with a raft if chamfers are not an option * Sand down edges (tedious for large parts) * Print part in such an orientation that elephant's foot doesn't matter * Fiddle with 3D printer settings until it prints right * If the part is too short, but the elephant foot doesn't really matter, make it taller in CAD (e.g. a spacer) [[File:Elephant-foot.jpg|thumb|Cube on the right has elephant foot]] ==== Hole Sizing (and general print sizing) ==== In general, 3d prints tend to be slightly wider horizontally than how they are designed in CAD. Part of this is due to printer filament squishing out, and part of it is because layers are not perfectly even/lined up, resulting in some higher bumps and uneven areas. As a result, holes printed using FDM printers usually end up a bit too small, and pegs/shafts end up a bit too big. There are two main solutions: * Offset faces "inward" by some amount in CAD. Some generally applicable values: ** 0.1 mm results in a tight fit (hammer/press required) ** 0.2 mm results in a fit that can be assembled by hand, but can't be relied on to freely rotate ** 0.3-0.4+ mm results in a fit that will freely rotate and move around * Accept that things might print too big and use sandpaper or a drill to fix it ** This often happens when the CAD is not updated ahead of time! ==== Warping ==== For prints with large, plate-like surfaces (e.g. boxes, plates, large components in general, etc.), corners may have a tendency to come off of the print bed. While this is more of a function of the quality of a 3D printer than anything else, there are a few remedies: * Change the design to another material/process if the design allows it, or split it into multiple smaller parts * Add fillets to corners on the face that is the first layer (sharp corners tend to warp more) * Add a brim or a raft to improve adhesion and follow the steps from the "Preventing Print Failures" section * Increase the nozzle temperature for the first layer, as well as the print bed temperature overall (this may cause drooping or increased elephant foot) === Preventing Print Failures === It is easy to accidentally produce spaghetti (or perhaps modern art, depending on your perspective) using an FDM printer. This happens when the print detaches from the print bed and slides around as material is added, resulting in fascinating results. ==== Design Issues ==== Spindly, narrow, and tall parts are generally more challenging to print successfully than low, wide, and boring parts. * If a design has large overhangs, try reorienting the part and/or splitting it into multiple easier to print parts * If a design has a first layer with little surface area, consider adding a brim or raft in the slicer * If a design requires long, narrow sheets or cylinders, consider changing the material to sheet metal or metal shafts that are later assembled ==== Print Setup Issues ==== Physical causes: * Print bed surface adhesion ** Wipe down with isopropyl alcohol on a paper towel to improve adhesion ** Blue masking tape on the print bed can also help adhesion * Print bed leveling ** Uneven/warped print beds can cause print failures ** Not leveling a print bed carefully can cause some areas to be too far from the nozzle to adhere correctly Slicing causes: * Part orientation issues: rotated to be tall/narrow instead of low/wide * Temperature set too low for print bed or nozzle * Not enough supports added for overhanging areas * Not using a brim or raft for challenging/detailed first layers === Improving Print Quality === FDM 3D printers, because of their layer-by-layer and extrusion-based method of building material up, result in some flaws in quality that are predictable and can be mitigated. ==== Overhangs ==== Because prints are built up layer-by-layer, layers need something under them to stay up. For the first layer, this is the plate, and for higher layers, the previous layers provide this support. An angle of 45 degrees from vertical without support can be printed by just about any printer, and most can do 60 degrees. However, for more extreme angles or for flat areas, additional considerations are needed. * Supports (dedicated/sacrificial material) can be added in the slicing software and removed after the print ** This uses additional material, increasing the cost and time required for the print ** The material in the actual part that is printed over the supports tends to have a rough and uneven surface ** They allow printing almost any shape, at the cost of some quality, time, and material * No supports, but material on either side (so the unsupported part is a "bridge" between pillars/walls) ** 3D printers can bridge considerable distances like this, but this works better for shorter distances * Converting the overhang into a slope: the design may or may not allow it, but this is the best option for quality ==== Stair-Stepping ==== The layer-by-layer nature of FDM printing means that prints are vertically "pixellated" into slabs. This means that features that are round looking from the side will be jagged, and for holes, some drooping/sagging may be present around the top. Remedies include: * Lowering the layer height (increasing the resolution) of the print, but this results in a longer print time ** A "dynamic layer height" option is available in many slicers that reduces the layer heights near high-detail sections, but increases it for low-detail sections * Changing the orientation of the print so that the axis of circles and arcs is vertical * Modify holes or other affected features to have slopes instead of flat areas * Avoid using fillets on lower edges, or switch them to chamfers 5b23132eff65ca01234d5430d619e67f114e4e86 309 307 2022-01-18T05:27:59Z Alnis S 6 wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === 3D printers produce parts relatively quickly but have certain quirks for how big they end up printing stuff. Most of these can be predicted and worked around by modifying the design or print settings, but it is important to be aware of common pitfalls and how to fix them. ==== Elephant Foot ==== For the first few layers of a print, to improve adhesion and prevent peeling/warping, the nozzle is often slightly closer to the plate than the thickness of the first layer. This results in material being squished out, resulting in a widening of the first few layers. This can cause issues with parts not fitting into tight spaces, parts not looking very good, and not having flat sides when necessary. Additionally, prints may end up slightly shorter than intended. To remedy this, there are a few options: * Apply a small (~0.4 to 0.8 mm) chamfer to the bottom of a part * Print with a raft if chamfers are not an option * Sand down edges (tedious for large parts) * Print part in such an orientation that elephant's foot doesn't matter * Fiddle with 3D printer settings until it prints right * If the part is too short, but the elephant foot doesn't really matter, make it taller in CAD (e.g. a spacer) [[File:Elephant-foot.jpg|thumb|Cube on the right has elephant foot]] ==== Hole Sizing (and general print sizing) ==== In general, 3d prints tend to be slightly wider horizontally than how they are designed in CAD. Part of this is due to printer filament squishing out, and part of it is because layers are not perfectly even/lined up, resulting in some higher bumps and uneven areas. As a result, holes printed using FDM printers usually end up a bit too small, and pegs/shafts end up a bit too big. There are two main solutions: * Offset faces "inward" by some amount in CAD. Some generally applicable values: ** 0.1 mm results in a tight fit (hammer/press required) ** 0.2 mm results in a fit that can be assembled by hand, but can't be relied on to freely rotate ** 0.3-0.4+ mm results in a fit that will freely rotate and move around * Accept that things might print too big and use sandpaper or a drill to fix it ** This often happens when the CAD is not updated ahead of time! ==== Warping ==== For prints with large, plate-like surfaces (e.g. boxes, plates, large components in general, etc.), corners may have a tendency to come off of the print bed. While this is more of a function of the quality of a 3D printer than anything else, there are a few remedies: * Change the design to another material/process if the design allows it, or split it into multiple smaller parts * Add fillets to corners on the face that is the first layer (sharp corners tend to warp more) * Add a brim or a raft to improve adhesion and follow the steps from the "Preventing Print Failures" section * Increase the nozzle temperature for the first layer, as well as the print bed temperature overall (this may cause drooping or increased elephant foot) === Preventing Print Failures === It is easy to accidentally produce spaghetti (or perhaps modern art, depending on your perspective) using an FDM printer. This happens when the print detaches from the print bed and slides around as material is added, resulting in fascinating results. ==== Design Issues ==== Spindly, narrow, and tall parts are generally more challenging to print successfully than low, wide, and boring parts. * If a design has large overhangs, try reorienting the part and/or splitting it into multiple easier to print parts * If a design has a first layer with little surface area, consider adding a brim or raft in the slicer * If a design requires long, narrow sheets or cylinders, consider changing the material to sheet metal or metal shafts that are later assembled ==== Print Setup Issues ==== Physical causes: * Print bed surface adhesion ** Wipe down with isopropyl alcohol on a paper towel to improve adhesion ** Blue masking tape on the print bed can also help adhesion * Print bed leveling ** Uneven/warped print beds can cause print failures ** Not leveling a print bed carefully can cause some areas to be too far from the nozzle to adhere correctly Slicing causes: * Part orientation issues: rotated to be tall/narrow instead of low/wide * Temperature set too low for print bed or nozzle * Not enough supports added for overhanging areas * Not using a brim or raft for challenging/detailed first layers === Improving Print Quality === FDM 3D printers, because of their layer-by-layer and extrusion-based method of building material up, result in some flaws in quality that are predictable and can be mitigated. ==== Overhangs ==== Because prints are built up layer-by-layer, layers need something under them to stay up. For the first layer, this is the plate, and for higher layers, the previous layers provide this support. An angle of 45 degrees from vertical without support can be printed by just about any printer, and most can do 60 degrees. However, for more extreme angles or for flat areas, additional considerations are needed. * Supports (dedicated/sacrificial material) can be added in the slicing software and removed after the print ** This uses additional material, increasing the cost and time required for the print ** The material in the actual part that is printed over the supports tends to have a rough and uneven surface ** They allow printing almost any shape, at the cost of some quality, time, and material * No supports, but material on either side (so the unsupported part is a "bridge" between pillars/walls) ** 3D printers can bridge considerable distances like this, but this works better for shorter distances * Converting the overhang into a slope: the design may or may not allow it, but this is the best option for quality ==== Stair-Stepping ==== The layer-by-layer nature of FDM printing means that prints are vertically "pixellated" into slabs. This means that features that are round looking from the side will be jagged, and for holes, some drooping/sagging may be present around the top. Remedies include: * Lowering the layer height (increasing the resolution) of the print, but this results in a longer print time ** A "dynamic layer height" option is available in many slicers that reduces the layer heights near high-detail sections, but increases it for low-detail sections * Changing the orientation of the print so that the axis of circles and arcs is vertical * Modify holes or other affected features to have slopes instead of flat areas * Avoid using fillets on lower edges, or switch them to chamfers === Summary === [[File:BillieRubenMake-3d-print-guide-infographic.jpg|frame|center|Summary of tips and tricks for designing for FDM 3D printing]] a016f85d7e785cd7d3932020fbd2994e4e8be172 310 309 2022-01-18T05:35:14Z Alnis S 6 wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === 3D printers produce parts relatively quickly but have certain quirks for how big they end up printing stuff. Most of these can be predicted and worked around by modifying the design or print settings, but it is important to be aware of common pitfalls and how to fix them. ==== Elephant Foot ==== For the first few layers of a print, to improve adhesion and prevent peeling/warping, the nozzle is often slightly closer to the plate than the thickness of the first layer. This results in material being squished out, resulting in a widening of the first few layers. This can cause issues with parts not fitting into tight spaces, parts not looking very good, and not having flat sides when necessary. Additionally, prints may end up slightly shorter than intended. To remedy this, there are a few options: * Apply a small (~0.4 to 0.8 mm) chamfer to the bottom of a part * Print with a raft if chamfers are not an option * Sand down edges (tedious for large parts) * Print part in such an orientation that elephant's foot doesn't matter * Fiddle with 3D printer settings until it prints right * If the part is too short, but the elephant foot doesn't really matter, make it taller in CAD (e.g. a spacer) [[File:Elephant-foot.jpg|thumb|Cube on the right has elephant foot]] ==== Hole Sizing (and general print sizing) ==== In general, 3d prints tend to be slightly wider horizontally than how they are designed in CAD. Part of this is due to printer filament squishing out, and part of it is because layers are not perfectly even/lined up, resulting in some higher bumps and uneven areas. As a result, holes printed using FDM printers usually end up a bit too small, and pegs/shafts end up a bit too big. There are two main solutions: * Offset faces "inward" by some amount in CAD. Some generally applicable values: ** 0.1 mm results in a tight fit (hammer/press required) ** 0.2 mm results in a fit that can be assembled by hand, but can't be relied on to freely rotate ** 0.3-0.4+ mm results in a fit that will freely rotate and move around * Accept that things might print too big and use sandpaper or a drill to fix it ** This often happens when the CAD is not updated ahead of time! ==== Warping ==== For prints with large, plate-like surfaces (e.g. boxes, plates, large components in general, etc.), corners may have a tendency to come off of the print bed. While this is more of a function of the quality of a 3D printer than anything else, there are a few remedies: * Change the design to another material/process if the design allows it, or split it into multiple smaller parts * Add fillets to corners on the face that is the first layer (sharp corners tend to warp more) * Add a brim or a raft to improve adhesion and follow the steps from the "Preventing Print Failures" section * Increase the nozzle temperature for the first layer, as well as the print bed temperature overall (this may cause drooping or increased elephant foot) === Preventing Print Failures === It is easy to accidentally produce spaghetti (or perhaps modern art, depending on your perspective) using an FDM printer. This happens when the print detaches from the print bed and slides around as material is added, resulting in fascinating results. ==== Design Issues ==== Spindly, narrow, and tall parts are generally more challenging to print successfully than low, wide, and boring parts. * If a design has large overhangs, try reorienting the part and/or splitting it into multiple easier to print parts * If a design has a first layer with little surface area, consider adding a brim or raft in the slicer * If a design requires long, narrow sheets or cylinders, consider changing the material to sheet metal or metal shafts that are later assembled ==== Print Setup Issues ==== Physical causes: * Print bed surface adhesion ** Wipe down with isopropyl alcohol on a paper towel to improve adhesion ** Blue masking tape on the print bed can also help adhesion * Print bed leveling ** Uneven/warped print beds can cause print failures ** Not leveling a print bed carefully can cause some areas to be too far from the nozzle to adhere correctly Slicing causes: * Part orientation issues: rotated to be tall/narrow instead of low/wide * Temperature set too low for print bed or nozzle * Not enough supports added for overhanging areas * Not using a brim or raft for challenging/detailed first layers === Improving Print Quality === FDM 3D printers, because of their layer-by-layer and extrusion-based method of building material up, result in some flaws in quality that are predictable and can be mitigated. ==== Overhangs ==== Because prints are built up layer-by-layer, layers need something under them to stay up. For the first layer, this is the plate, and for higher layers, the previous layers provide this support. An angle of 45 degrees from vertical without support can be printed by just about any printer, and most can do 60 degrees. However, for more extreme angles or for flat areas, additional considerations are needed. * Supports (dedicated/sacrificial material) can be added in the slicing software and removed after the print ** This uses additional material, increasing the cost and time required for the print ** The material in the actual part that is printed over the supports tends to have a rough and uneven surface ** They allow printing almost any shape, at the cost of some quality, time, and material * No supports, but material on either side (so the unsupported part is a "bridge" between pillars/walls) ** 3D printers can bridge considerable distances like this, but this works better for shorter distances * Converting the overhang into a slope: the design may or may not allow it, but this is the best option for quality ==== Stair-Stepping ==== The layer-by-layer nature of FDM printing means that prints are vertically "pixellated" into slabs. This means that features that are round looking from the side will be jagged, and for holes, some drooping/sagging may be present around the top. Remedies include: * Lowering the layer height (increasing the resolution) of the print, but this results in a longer print time ** A "dynamic layer height" option is available in many slicers that reduces the layer heights near high-detail sections, but increases it for low-detail sections * Changing the orientation of the print so that the axis of circles and arcs is vertical * Modify holes or other affected features to have slopes instead of flat areas * Avoid using fillets on lower edges, or switch them to chamfers === Summary === [[File:BillieRubenMake-3d-print-guide-infographic.jpg|400px|thumb|none|Summary of tips and tricks for designing for FDM 3D printing]] da70220d09febf40b9a9e8dc000868277f553651 311 310 2022-01-18T05:36:52Z Alnis S 6 /* Summary */ wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === 3D printers produce parts relatively quickly but have certain quirks for how big they end up printing stuff. Most of these can be predicted and worked around by modifying the design or print settings, but it is important to be aware of common pitfalls and how to fix them. ==== Elephant Foot ==== For the first few layers of a print, to improve adhesion and prevent peeling/warping, the nozzle is often slightly closer to the plate than the thickness of the first layer. This results in material being squished out, resulting in a widening of the first few layers. This can cause issues with parts not fitting into tight spaces, parts not looking very good, and not having flat sides when necessary. Additionally, prints may end up slightly shorter than intended. To remedy this, there are a few options: * Apply a small (~0.4 to 0.8 mm) chamfer to the bottom of a part * Print with a raft if chamfers are not an option * Sand down edges (tedious for large parts) * Print part in such an orientation that elephant's foot doesn't matter * Fiddle with 3D printer settings until it prints right * If the part is too short, but the elephant foot doesn't really matter, make it taller in CAD (e.g. a spacer) [[File:Elephant-foot.jpg|thumb|Cube on the right has elephant foot]] ==== Hole Sizing (and general print sizing) ==== In general, 3d prints tend to be slightly wider horizontally than how they are designed in CAD. Part of this is due to printer filament squishing out, and part of it is because layers are not perfectly even/lined up, resulting in some higher bumps and uneven areas. As a result, holes printed using FDM printers usually end up a bit too small, and pegs/shafts end up a bit too big. There are two main solutions: * Offset faces "inward" by some amount in CAD. Some generally applicable values: ** 0.1 mm results in a tight fit (hammer/press required) ** 0.2 mm results in a fit that can be assembled by hand, but can't be relied on to freely rotate ** 0.3-0.4+ mm results in a fit that will freely rotate and move around * Accept that things might print too big and use sandpaper or a drill to fix it ** This often happens when the CAD is not updated ahead of time! ==== Warping ==== For prints with large, plate-like surfaces (e.g. boxes, plates, large components in general, etc.), corners may have a tendency to come off of the print bed. While this is more of a function of the quality of a 3D printer than anything else, there are a few remedies: * Change the design to another material/process if the design allows it, or split it into multiple smaller parts * Add fillets to corners on the face that is the first layer (sharp corners tend to warp more) * Add a brim or a raft to improve adhesion and follow the steps from the "Preventing Print Failures" section * Increase the nozzle temperature for the first layer, as well as the print bed temperature overall (this may cause drooping or increased elephant foot) === Preventing Print Failures === It is easy to accidentally produce spaghetti (or perhaps modern art, depending on your perspective) using an FDM printer. This happens when the print detaches from the print bed and slides around as material is added, resulting in fascinating results. ==== Design Issues ==== Spindly, narrow, and tall parts are generally more challenging to print successfully than low, wide, and boring parts. * If a design has large overhangs, try reorienting the part and/or splitting it into multiple easier to print parts * If a design has a first layer with little surface area, consider adding a brim or raft in the slicer * If a design requires long, narrow sheets or cylinders, consider changing the material to sheet metal or metal shafts that are later assembled ==== Print Setup Issues ==== Physical causes: * Print bed surface adhesion ** Wipe down with isopropyl alcohol on a paper towel to improve adhesion ** Blue masking tape on the print bed can also help adhesion * Print bed leveling ** Uneven/warped print beds can cause print failures ** Not leveling a print bed carefully can cause some areas to be too far from the nozzle to adhere correctly Slicing causes: * Part orientation issues: rotated to be tall/narrow instead of low/wide * Temperature set too low for print bed or nozzle * Not enough supports added for overhanging areas * Not using a brim or raft for challenging/detailed first layers === Improving Print Quality === FDM 3D printers, because of their layer-by-layer and extrusion-based method of building material up, result in some flaws in quality that are predictable and can be mitigated. ==== Overhangs ==== Because prints are built up layer-by-layer, layers need something under them to stay up. For the first layer, this is the plate, and for higher layers, the previous layers provide this support. An angle of 45 degrees from vertical without support can be printed by just about any printer, and most can do 60 degrees. However, for more extreme angles or for flat areas, additional considerations are needed. * Supports (dedicated/sacrificial material) can be added in the slicing software and removed after the print ** This uses additional material, increasing the cost and time required for the print ** The material in the actual part that is printed over the supports tends to have a rough and uneven surface ** They allow printing almost any shape, at the cost of some quality, time, and material * No supports, but material on either side (so the unsupported part is a "bridge" between pillars/walls) ** 3D printers can bridge considerable distances like this, but this works better for shorter distances * Converting the overhang into a slope: the design may or may not allow it, but this is the best option for quality ==== Stair-Stepping ==== The layer-by-layer nature of FDM printing means that prints are vertically "pixellated" into slabs. This means that features that are round looking from the side will be jagged, and for holes, some drooping/sagging may be present around the top. Remedies include: * Lowering the layer height (increasing the resolution) of the print, but this results in a longer print time ** A "dynamic layer height" option is available in many slicers that reduces the layer heights near high-detail sections, but increases it for low-detail sections * Changing the orientation of the print so that the axis of circles and arcs is vertical * Modify holes or other affected features to have slopes instead of flat areas * Avoid using fillets on lower edges, or switch them to chamfers === Summary === Here is a wonderful infographic from @BillieRubenMake (https://twitter.com/billierubenmake/status/1152525801528496128?lang=en): [[File:BillieRubenMake-3d-print-guide-infographic.jpg|400px|thumb|none|Summary of tips and tricks for designing for FDM 3D printing]] 929ceb71d6fe7adc4ea8cb201bca6a63819dad18 312 311 2022-01-18T05:37:22Z Alnis S 6 /* Elephant Foot */ wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === 3D printers produce parts relatively quickly but have certain quirks for how big they end up printing stuff. Most of these can be predicted and worked around by modifying the design or print settings, but it is important to be aware of common pitfalls and how to fix them. ==== Elephant Foot ==== [[File:Elephant-foot.jpg|thumb|Cube on the right has elephant foot]] For the first few layers of a print, to improve adhesion and prevent peeling/warping, the nozzle is often slightly closer to the plate than the thickness of the first layer. This results in material being squished out, resulting in a widening of the first few layers. This can cause issues with parts not fitting into tight spaces, parts not looking very good, and not having flat sides when necessary. Additionally, prints may end up slightly shorter than intended. To remedy this, there are a few options: * Apply a small (~0.4 to 0.8 mm) chamfer to the bottom of a part * Print with a raft if chamfers are not an option * Sand down edges (tedious for large parts) * Print part in such an orientation that elephant's foot doesn't matter * Fiddle with 3D printer settings until it prints right * If the part is too short, but the elephant foot doesn't really matter, make it taller in CAD (e.g. a spacer) ==== Hole Sizing (and general print sizing) ==== In general, 3d prints tend to be slightly wider horizontally than how they are designed in CAD. Part of this is due to printer filament squishing out, and part of it is because layers are not perfectly even/lined up, resulting in some higher bumps and uneven areas. As a result, holes printed using FDM printers usually end up a bit too small, and pegs/shafts end up a bit too big. There are two main solutions: * Offset faces "inward" by some amount in CAD. Some generally applicable values: ** 0.1 mm results in a tight fit (hammer/press required) ** 0.2 mm results in a fit that can be assembled by hand, but can't be relied on to freely rotate ** 0.3-0.4+ mm results in a fit that will freely rotate and move around * Accept that things might print too big and use sandpaper or a drill to fix it ** This often happens when the CAD is not updated ahead of time! ==== Warping ==== For prints with large, plate-like surfaces (e.g. boxes, plates, large components in general, etc.), corners may have a tendency to come off of the print bed. While this is more of a function of the quality of a 3D printer than anything else, there are a few remedies: * Change the design to another material/process if the design allows it, or split it into multiple smaller parts * Add fillets to corners on the face that is the first layer (sharp corners tend to warp more) * Add a brim or a raft to improve adhesion and follow the steps from the "Preventing Print Failures" section * Increase the nozzle temperature for the first layer, as well as the print bed temperature overall (this may cause drooping or increased elephant foot) === Preventing Print Failures === It is easy to accidentally produce spaghetti (or perhaps modern art, depending on your perspective) using an FDM printer. This happens when the print detaches from the print bed and slides around as material is added, resulting in fascinating results. ==== Design Issues ==== Spindly, narrow, and tall parts are generally more challenging to print successfully than low, wide, and boring parts. * If a design has large overhangs, try reorienting the part and/or splitting it into multiple easier to print parts * If a design has a first layer with little surface area, consider adding a brim or raft in the slicer * If a design requires long, narrow sheets or cylinders, consider changing the material to sheet metal or metal shafts that are later assembled ==== Print Setup Issues ==== Physical causes: * Print bed surface adhesion ** Wipe down with isopropyl alcohol on a paper towel to improve adhesion ** Blue masking tape on the print bed can also help adhesion * Print bed leveling ** Uneven/warped print beds can cause print failures ** Not leveling a print bed carefully can cause some areas to be too far from the nozzle to adhere correctly Slicing causes: * Part orientation issues: rotated to be tall/narrow instead of low/wide * Temperature set too low for print bed or nozzle * Not enough supports added for overhanging areas * Not using a brim or raft for challenging/detailed first layers === Improving Print Quality === FDM 3D printers, because of their layer-by-layer and extrusion-based method of building material up, result in some flaws in quality that are predictable and can be mitigated. ==== Overhangs ==== Because prints are built up layer-by-layer, layers need something under them to stay up. For the first layer, this is the plate, and for higher layers, the previous layers provide this support. An angle of 45 degrees from vertical without support can be printed by just about any printer, and most can do 60 degrees. However, for more extreme angles or for flat areas, additional considerations are needed. * Supports (dedicated/sacrificial material) can be added in the slicing software and removed after the print ** This uses additional material, increasing the cost and time required for the print ** The material in the actual part that is printed over the supports tends to have a rough and uneven surface ** They allow printing almost any shape, at the cost of some quality, time, and material * No supports, but material on either side (so the unsupported part is a "bridge" between pillars/walls) ** 3D printers can bridge considerable distances like this, but this works better for shorter distances * Converting the overhang into a slope: the design may or may not allow it, but this is the best option for quality ==== Stair-Stepping ==== The layer-by-layer nature of FDM printing means that prints are vertically "pixellated" into slabs. This means that features that are round looking from the side will be jagged, and for holes, some drooping/sagging may be present around the top. Remedies include: * Lowering the layer height (increasing the resolution) of the print, but this results in a longer print time ** A "dynamic layer height" option is available in many slicers that reduces the layer heights near high-detail sections, but increases it for low-detail sections * Changing the orientation of the print so that the axis of circles and arcs is vertical * Modify holes or other affected features to have slopes instead of flat areas * Avoid using fillets on lower edges, or switch them to chamfers === Summary === Here is a wonderful infographic from @BillieRubenMake (https://twitter.com/billierubenmake/status/1152525801528496128?lang=en): [[File:BillieRubenMake-3d-print-guide-infographic.jpg|400px|thumb|none|Summary of tips and tricks for designing for FDM 3D printing]] 5a9f0d6d6bdc76bfd113ee40643831e542abd948 314 312 2022-01-18T05:50:56Z Alnis S 6 /* Hole Sizing (and general print sizing) */ wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === 3D printers produce parts relatively quickly but have certain quirks for how big they end up printing stuff. Most of these can be predicted and worked around by modifying the design or print settings, but it is important to be aware of common pitfalls and how to fix them. ==== Elephant Foot ==== [[File:Elephant-foot.jpg|thumb|Cube on the right has elephant foot]] For the first few layers of a print, to improve adhesion and prevent peeling/warping, the nozzle is often slightly closer to the plate than the thickness of the first layer. This results in material being squished out, resulting in a widening of the first few layers. This can cause issues with parts not fitting into tight spaces, parts not looking very good, and not having flat sides when necessary. Additionally, prints may end up slightly shorter than intended. To remedy this, there are a few options: * Apply a small (~0.4 to 0.8 mm) chamfer to the bottom of a part * Print with a raft if chamfers are not an option * Sand down edges (tedious for large parts) * Print part in such an orientation that elephant's foot doesn't matter * Fiddle with 3D printer settings until it prints right * If the part is too short, but the elephant foot doesn't really matter, make it taller in CAD (e.g. a spacer) ==== Hole Sizing (and general print sizing) ==== [[File:Hole demo for onshape widening hole move face.png|thumb|Widening a hole in Onshape to ensure the resulting hole prints at the right size]] In general, 3d prints tend to be slightly wider horizontally than how they are designed in CAD. Part of this is due to printer filament squishing out, and part of it is because layers are not perfectly even/lined up, resulting in some higher bumps and uneven areas. As a result, holes printed using FDM printers usually end up a bit too small, and pegs/shafts end up a bit too big. There are two main solutions: * Offset faces "inward" by some amount in CAD. Some generally applicable values: ** 0.1 mm results in a tight fit (hammer/press required) ** 0.2 mm results in a fit that can be assembled by hand, but can't be relied on to freely rotate ** 0.3-0.4+ mm results in a fit that will freely rotate and move around * Accept that things might print too big and use sandpaper or a drill to fix it ** This often happens when the CAD is not updated ahead of time! ==== Warping ==== For prints with large, plate-like surfaces (e.g. boxes, plates, large components in general, etc.), corners may have a tendency to come off of the print bed. While this is more of a function of the quality of a 3D printer than anything else, there are a few remedies: * Change the design to another material/process if the design allows it, or split it into multiple smaller parts * Add fillets to corners on the face that is the first layer (sharp corners tend to warp more) * Add a brim or a raft to improve adhesion and follow the steps from the "Preventing Print Failures" section * Increase the nozzle temperature for the first layer, as well as the print bed temperature overall (this may cause drooping or increased elephant foot) === Preventing Print Failures === It is easy to accidentally produce spaghetti (or perhaps modern art, depending on your perspective) using an FDM printer. This happens when the print detaches from the print bed and slides around as material is added, resulting in fascinating results. ==== Design Issues ==== Spindly, narrow, and tall parts are generally more challenging to print successfully than low, wide, and boring parts. * If a design has large overhangs, try reorienting the part and/or splitting it into multiple easier to print parts * If a design has a first layer with little surface area, consider adding a brim or raft in the slicer * If a design requires long, narrow sheets or cylinders, consider changing the material to sheet metal or metal shafts that are later assembled ==== Print Setup Issues ==== Physical causes: * Print bed surface adhesion ** Wipe down with isopropyl alcohol on a paper towel to improve adhesion ** Blue masking tape on the print bed can also help adhesion * Print bed leveling ** Uneven/warped print beds can cause print failures ** Not leveling a print bed carefully can cause some areas to be too far from the nozzle to adhere correctly Slicing causes: * Part orientation issues: rotated to be tall/narrow instead of low/wide * Temperature set too low for print bed or nozzle * Not enough supports added for overhanging areas * Not using a brim or raft for challenging/detailed first layers === Improving Print Quality === FDM 3D printers, because of their layer-by-layer and extrusion-based method of building material up, result in some flaws in quality that are predictable and can be mitigated. ==== Overhangs ==== Because prints are built up layer-by-layer, layers need something under them to stay up. For the first layer, this is the plate, and for higher layers, the previous layers provide this support. An angle of 45 degrees from vertical without support can be printed by just about any printer, and most can do 60 degrees. However, for more extreme angles or for flat areas, additional considerations are needed. * Supports (dedicated/sacrificial material) can be added in the slicing software and removed after the print ** This uses additional material, increasing the cost and time required for the print ** The material in the actual part that is printed over the supports tends to have a rough and uneven surface ** They allow printing almost any shape, at the cost of some quality, time, and material * No supports, but material on either side (so the unsupported part is a "bridge" between pillars/walls) ** 3D printers can bridge considerable distances like this, but this works better for shorter distances * Converting the overhang into a slope: the design may or may not allow it, but this is the best option for quality ==== Stair-Stepping ==== The layer-by-layer nature of FDM printing means that prints are vertically "pixellated" into slabs. This means that features that are round looking from the side will be jagged, and for holes, some drooping/sagging may be present around the top. Remedies include: * Lowering the layer height (increasing the resolution) of the print, but this results in a longer print time ** A "dynamic layer height" option is available in many slicers that reduces the layer heights near high-detail sections, but increases it for low-detail sections * Changing the orientation of the print so that the axis of circles and arcs is vertical * Modify holes or other affected features to have slopes instead of flat areas * Avoid using fillets on lower edges, or switch them to chamfers === Summary === Here is a wonderful infographic from @BillieRubenMake (https://twitter.com/billierubenmake/status/1152525801528496128?lang=en): [[File:BillieRubenMake-3d-print-guide-infographic.jpg|400px|thumb|none|Summary of tips and tricks for designing for FDM 3D printing]] caa9b4642df7d25b327775e092a37a34f844ed7d 315 314 2022-01-18T05:56:10Z Alnis S 6 /* Design Issues */ wikitext text/x-wiki == FDM Printer Tips == FDM (Fused Deposition Modeling) printers work by building a model out of plastic layer-by-layer on a flat plate. They generally use inexpensive material, have large print volumes, and some models can print with a wide range of plastics, including nylon and flexible rubber-like material. However, compared to other 3D printer types, they tend to have dimensional accuracy issues, are more prone to warped and failed prints, and can have more quality issues. === Improving Dimensional Accuracy === 3D printers produce parts relatively quickly but have certain quirks for how big they end up printing stuff. Most of these can be predicted and worked around by modifying the design or print settings, but it is important to be aware of common pitfalls and how to fix them. ==== Elephant Foot ==== [[File:Elephant-foot.jpg|thumb|Cube on the right has elephant foot]] For the first few layers of a print, to improve adhesion and prevent peeling/warping, the nozzle is often slightly closer to the plate than the thickness of the first layer. This results in material being squished out, resulting in a widening of the first few layers. This can cause issues with parts not fitting into tight spaces, parts not looking very good, and not having flat sides when necessary. Additionally, prints may end up slightly shorter than intended. To remedy this, there are a few options: * Apply a small (~0.4 to 0.8 mm) chamfer to the bottom of a part * Print with a raft if chamfers are not an option * Sand down edges (tedious for large parts) * Print part in such an orientation that elephant's foot doesn't matter * Fiddle with 3D printer settings until it prints right * If the part is too short, but the elephant foot doesn't really matter, make it taller in CAD (e.g. a spacer) ==== Hole Sizing (and general print sizing) ==== [[File:Hole demo for onshape widening hole move face.png|thumb|Widening a hole in Onshape to ensure the resulting hole prints at the right size]] In general, 3d prints tend to be slightly wider horizontally than how they are designed in CAD. Part of this is due to printer filament squishing out, and part of it is because layers are not perfectly even/lined up, resulting in some higher bumps and uneven areas. As a result, holes printed using FDM printers usually end up a bit too small, and pegs/shafts end up a bit too big. There are two main solutions: * Offset faces "inward" by some amount in CAD. Some generally applicable values: ** 0.1 mm results in a tight fit (hammer/press required) ** 0.2 mm results in a fit that can be assembled by hand, but can't be relied on to freely rotate ** 0.3-0.4+ mm results in a fit that will freely rotate and move around * Accept that things might print too big and use sandpaper or a drill to fix it ** This often happens when the CAD is not updated ahead of time! ==== Warping ==== For prints with large, plate-like surfaces (e.g. boxes, plates, large components in general, etc.), corners may have a tendency to come off of the print bed. While this is more of a function of the quality of a 3D printer than anything else, there are a few remedies: * Change the design to another material/process if the design allows it, or split it into multiple smaller parts * Add fillets to corners on the face that is the first layer (sharp corners tend to warp more) * Add a brim or a raft to improve adhesion and follow the steps from the "Preventing Print Failures" section * Increase the nozzle temperature for the first layer, as well as the print bed temperature overall (this may cause drooping or increased elephant foot) === Preventing Print Failures === It is easy to accidentally produce spaghetti (or perhaps modern art, depending on your perspective) using an FDM printer. This happens when the print detaches from the print bed and slides around as material is added, resulting in fascinating results. ==== Design Issues ==== Spindly, narrow, and tall parts are generally more challenging to print successfully than low, wide, and boring parts. * If a design has large overhangs, try reorienting the part and/or splitting it into multiple easier to print parts * If a design has a first layer with little surface area, consider adding a brim or raft in the slicer * If a design requires long, narrow sheets or cylinders, consider changing the material to sheet metal or metal shafts that are later assembled * If parts are very small (such as spacers), consider connecting them to minimize the risk of them falling off during printing, then cut them apart after printing ==== Print Setup Issues ==== Physical causes: * Print bed surface adhesion ** Wipe down with isopropyl alcohol on a paper towel to improve adhesion ** Blue masking tape on the print bed can also help adhesion * Print bed leveling ** Uneven/warped print beds can cause print failures ** Not leveling a print bed carefully can cause some areas to be too far from the nozzle to adhere correctly Slicing causes: * Part orientation issues: rotated to be tall/narrow instead of low/wide * Temperature set too low for print bed or nozzle * Not enough supports added for overhanging areas * Not using a brim or raft for challenging/detailed first layers === Improving Print Quality === FDM 3D printers, because of their layer-by-layer and extrusion-based method of building material up, result in some flaws in quality that are predictable and can be mitigated. ==== Overhangs ==== Because prints are built up layer-by-layer, layers need something under them to stay up. For the first layer, this is the plate, and for higher layers, the previous layers provide this support. An angle of 45 degrees from vertical without support can be printed by just about any printer, and most can do 60 degrees. However, for more extreme angles or for flat areas, additional considerations are needed. * Supports (dedicated/sacrificial material) can be added in the slicing software and removed after the print ** This uses additional material, increasing the cost and time required for the print ** The material in the actual part that is printed over the supports tends to have a rough and uneven surface ** They allow printing almost any shape, at the cost of some quality, time, and material * No supports, but material on either side (so the unsupported part is a "bridge" between pillars/walls) ** 3D printers can bridge considerable distances like this, but this works better for shorter distances * Converting the overhang into a slope: the design may or may not allow it, but this is the best option for quality ==== Stair-Stepping ==== The layer-by-layer nature of FDM printing means that prints are vertically "pixellated" into slabs. This means that features that are round looking from the side will be jagged, and for holes, some drooping/sagging may be present around the top. Remedies include: * Lowering the layer height (increasing the resolution) of the print, but this results in a longer print time ** A "dynamic layer height" option is available in many slicers that reduces the layer heights near high-detail sections, but increases it for low-detail sections * Changing the orientation of the print so that the axis of circles and arcs is vertical * Modify holes or other affected features to have slopes instead of flat areas * Avoid using fillets on lower edges, or switch them to chamfers === Summary === Here is a wonderful infographic from @BillieRubenMake (https://twitter.com/billierubenmake/status/1152525801528496128?lang=en): [[File:BillieRubenMake-3d-print-guide-infographic.jpg|400px|thumb|none|Summary of tips and tricks for designing for FDM 3D printing]] db62227ed12973c8f983b69424b4237a15ee25d4 6 44 304 2022-01-18T03:18:16Z Alnis S 6 Image of Elephant Foot in 3d printing. Source: https://shop.anet3d.com/blogs/cura-slicer-profile-settings/use-xyz-calibration-cube-to-detect-3d-printing-issues-and-tune-your-3d-printer wikitext text/x-wiki == Summary == Image of Elephant Foot in 3d printing. Source: https://shop.anet3d.com/blogs/cura-slicer-profile-settings/use-xyz-calibration-cube-to-detect-3d-printing-issues-and-tune-your-3d-printer fa08bef8e30135fca7b89594524b6d53cb9d9a1b 6 45 308 2022-01-18T05:27:18Z Alnis S 6 Source: https://twitter.com/billierubenmake/status/1152525801528496128?lang=en wikitext text/x-wiki == Summary == Source: https://twitter.com/billierubenmake/status/1152525801528496128?lang=en 1c0e235837e918b40eefa3d00668681d94e0d72b 6 46 313 2022-01-18T05:50:13Z Alnis S 6 wikitext text/x-wiki Using move face to widen holes so that they are the right size after printing 7292befbfaf2f6a0df11dbdd74b770ac9590da02 0 3 319 67 2022-02-08T23:36:31Z Gunarp 7 wikitext text/x-wiki Welcome to the UWROV Software Team! On this page you'll find a few quick start references to help you get oriented to working on the team (or serve as a nice refresher on who we are and what we do). Check the Table of Contents to jump to any specific piece of information you're looking for! Alternatively, check out any guide on its own page! * [[Software/Quick Start Guides/UWROV Software Team Overview | Team Overview]] * [[Software/Quick Start Guides/Development | Development]] * [[Software/Quick Start Guides/Interface | Interface]] * [[Software/Quick Start Guides/ROS | ROS]] * [[Software/Quick Start Guides/Sim | Simulator]] {{/UWROV Software Team Overview}} {{/Development}} {{/Interface}} {{/ROS}} ed53ca351c5a8454544f2d86ec0965ddcf08dc61 6 47 320 2022-02-11T04:21:12Z Gunarp 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 48 321 2022-02-11T05:35:11Z Gunarp 7 Created page with "= ROV Sim = This page will go over some high level details on how our ROV simulation works, with details that will be helpful when making changes to it. Check out [https://github.com/uwrov/nautilus_sim the simulator's github repo] for instructions on how to run the simulator. == Software Used == Our simulator runs on [http://gazebosim.org/ Gazebo], a robotics simulation software often paired with ROS. Gazebo simulates a robot, its sensors, any props it might interact wi..." wikitext text/x-wiki = ROV Sim = This page will go over some high level details on how our ROV simulation works, with details that will be helpful when making changes to it. Check out [https://github.com/uwrov/nautilus_sim the simulator's github repo] for instructions on how to run the simulator. == Software Used == Our simulator runs on [http://gazebosim.org/ Gazebo], a robotics simulation software often paired with ROS. Gazebo simulates a robot, its sensors, any props it might interact with, and the world everything is in. Gazebo is typically split into a number of processes: ;gzserver : Process which handles all the actual simulation. Responsible for the physics update loop and sensor data generation. ;gzclient : Commonly used QT based client program which lets us view and interact with the simulation managed by <code>gzserver</code> ;gzweb : Alternative web based client to view and interact with <code>gzserver</code>. Has less functionality and is overall more buggy than <code>gzclient</code> Our simulator uses '''gzserver''' and '''gzweb'''. We choose <code>gzweb</code> over <code>gzclient</code> because all our software is packaged in containers. It is easier to run a client over a webpage than a QT application from a container. Gazebo comes with some ROS integrations, which allow Gazebo to publish and subscribe to ROS topics. This lets us interact with the simulated ROV with the same topics we use on the real ROV. == Models == Any object simulated by gazebo is defined by a model. And a model is made of multiple links. Here are the key components of a link: ;Collision : The shape of the model. Can be either a simple shape (faster, less accurate) or a triangle mesh (more computationally expensive, more accurate). ;Visual : What the model looks like, has little impact on the speed of the simulation. ;Inertial : Mass and interias of the model. Used in calculating how the model moves. === Xacro vs URDF vs SDF === [https://newscrewdriver.com/2018/07/31/ros-notes-urdf-vs-gazebo-sdf/ Article on URDF vs SDF] ;xacro : A macro language for XML. Used to clean up our URDF files. : The '''.urdf.xacro''' file contains XML macros and instantiations of the robot model. : The '''.gazebo''' file contains information on how gazebo plugins will interact with links on the model. ;URDF : ''U''nified ''R''obot ''D''escription ''F''ormat. An XML language used by ROS to describe a single robot. ;SDF : ''S''imulation ''D''escription ''F''ormat. Another XML language used by Gazebo which describes the starting state of a simulated world. When editing a robot mode in our simulator, the general process will look like editing a pair of <code>.urdf.xacro</code> and <code>.gazebo</code> files, and then compiling those files to a <code>.urdf</code> file. The <code>.urdf</code> file can be spawned into Gazebo, where it will be implicitly converted into <code>.sdf</code>. [[File:files-compile.png|border|How all the different file types relate to one another.]] == Plugins == Plugins add extra functionality to our simulation. === Buoyancy Plugin === === Thruster Plugin === 14604e62e40a5aa1dc559ffc5d4ac134cae0c456 323 321 2022-02-12T01:57:26Z Gunarp 7 wikitext text/x-wiki = ROV Sim = This page will go over some high level details on how our ROV simulation works, with details that will be helpful when making changes to it. Check out [https://github.com/uwrov/nautilus_sim the simulator's github repo] for instructions on how to run the simulator. == Some Quick Notes == * The sim uses meters as the primary unit * The ROV is facing the <code>-y</code> direction by default, keep this in mind when editing your model. * When panning/rotating your view in <code>gzweb</code>, the view will be centered around whatever you're clicking on. Always click on the model you want to rotate/pan around. * Pay attention to the <code>Real Time</code> and <code>Sim Time</code> readings in the top right of <code>gzweb</code> when evaluating simulation speed. If the real time is far ahead of the sim time, then the simulator is lagging. [[File:sim-axes.png|frame|How the ROV is oriented when first spawned]] == Software Used == Our simulator runs on [http://gazebosim.org/ Gazebo], a robotics simulation software often paired with ROS. Gazebo simulates a robot, its sensors, any props it might interact with, and the world everything is in. Gazebo is typically split into a number of processes: ;gzserver : Process which handles all the actual simulation. Responsible for the physics update loop and sensor data generation. ;gzclient : Commonly used QT based client program which lets us view and interact with the simulation managed by <code>gzserver</code> ;gzweb : Alternative web based client to view and interact with <code>gzserver</code>. Has less functionality and is overall more buggy than <code>gzclient</code> Our simulator uses '''gzserver''' and '''gzweb'''. We choose <code>gzweb</code> over <code>gzclient</code> because all our software is packaged in containers. It is easier to run a client over a webpage than a QT application from a container. Gazebo comes with some ROS integrations, which allow Gazebo to publish and subscribe to ROS topics. This lets us interact with the simulated ROV with the same topics we use on the real ROV. == Models == Any object simulated by gazebo is defined by a model. And a model is made of multiple links. Here are the key components of a link: ;Collision : The shape of the model. Can be either a simple shape (faster, less accurate) or a triangle mesh (more computationally expensive, more accurate). ;Visual : What the model looks like, has little impact on the speed of the simulation. ;Inertial : Mass and interias of the model. Used in calculating how the model moves. === Xacro vs URDF vs SDF === [https://newscrewdriver.com/2018/07/31/ros-notes-urdf-vs-gazebo-sdf/ Article on URDF vs SDF] ;xacro : A macro language for XML. Used to clean up our URDF files. : The '''.urdf.xacro''' file contains XML macros and instantiations of the robot model. : The '''.gazebo''' file contains information on how gazebo plugins will interact with links on the model. ;URDF : ''U''nified ''R''obot ''D''escription ''F''ormat. An XML language used by ROS to describe a single robot. ;SDF : ''S''imulation ''D''escription ''F''ormat. Another XML language used by Gazebo which describes the starting state of a simulated world. You ''could'' stick to only editing <code>.sdf</code> files, but we define our robots using <code>xacro</code>. <code>xacro</code> gives us the ability to define macros and variables in our XML, which are immensely helpful when making changes to our models. Here is the general workflow of editing a model named <code>**</code>: # Edit xacro files (ending in <code>**.urdf.xacro</code> or <code>.gazebo</code>) by hand. ## Keep variables and macro definitions/instantiations in the '''.urdf.xacro''' file. This file should also have a link to include the contents of the '''.gazebo''' file. ## Keep Gazebo specific blocks inside the '''.gazebo''' file (plugins, sensors, any special instructions Gazebo should take when converting URDF to SDF). # Verify validity of xacro file with <code>check_urdf <(xacro **.urdf.xacro)</code> # Compile the xacro file to a URDF file using <code>xacro **.urdf.xacro > **.urdf</code> # Spawn the model in a running Gazebo instance with <code>rosrun gazebo_ros spawn_model -f **.urdf -urdf -model **</code> [[File:files-compile.png|border|How all the different file types relate to one another.]] === Meshes === The simulator is able to take in a 3d model formatted in <code>.dae</code>, <code>.stl</code>, or <code>.obj</code> for collision and visual definitions of a link. '''.dae''' is the preferred format. == Plugins == Plugins add extra functionality to our simulation. There are many kinds of plugins, you can read about them [http://gazebosim.org/tutorials?tut=plugins_hello_world&cat=write_plugin here (basics)] and [http://gazebosim.org/tutorials?tut=ros_gzplugins here (some handy ROS ready ones)]. === Buoyancy Plugin === The simulator uses Gazebo's [https://gazebosim.org/tutorials?tut=hydrodynamics&cat=physics BuoyancyPlugin] to simulate the buoyant force on the ROV. === Thruster Plugin === The simulator uses a [https://github.com/uwrov/nautilus_sim/tree/main/src/nautilus_worlds/src basic model plugin] to simulate the thrusters of the ROV. Here's an outline on how the plugin works: # The source code for the plugin is compiled to a shared object <code>.so</code> file when running <code>catkin_make</code>. So any changes to the plugin require a <code>catkin_make</code> to be seen. # The shared object is connected to a link in the simulation in a <code>.gazebo</code> file. # The plugin is constructed and loaded when the model is spawned. The plugin subscribes to <code>/nautilus/thrusters/pwm</code>. # On every world update, the plugin sets the force on each of the thrusters according to the last reading of <code>/nautilus/thrusters/pwm</code> ## 6-long int arrays are constantly published to <code>/nautilus/thrusters/pwm</code>. The plugin reads these arrays and applies the PWMs onto the motors in order of A-F, which are named in the <code>.xacro.urdf</code> file. ## A PWM is converted to a force on a thruster. ### Valid PWMs lie in range <code>[1000, 2000]</code>. <code>1000</code> is max reverse thrust, <code>2000</code> is max forward thrust, and <code>1500</code> is no thrust. ### The PWMs are mapped to a thrust value, described in the table below. #### Motors A-D are T100, E and F are both T200 motors. This can be changed by modifying the <code>num_t100_</code> variable of [https://github.com/uwrov/nautilus_sim/blob/main/src/nautilus_worlds/src/thruster_manager.h#L44 <code>thruster_manager.h</code>] ### The force is converted to <code>N</code> and applied onto the corresponding thruster link. Then the ROV moves! {| class="wikitable" style="margin-left: auto; margin-right: auto;" |+Thrust Mappings (PWM to <code>kg f</code>) |- !scope="col"| PWM !scope="col"| T100 !scope="col"| T200 |- !scope="row"| [1000, 1500) | [-1.82, 0) | [-4.1, 0) |- !scope="row"| [1500, 2000] | [0, 2.36] | [0, 5.25] |} 16f50520513b264f2cf73deeb5f39f032caaf043 324 323 2022-02-12T01:58:34Z Gunarp 7 /* Thruster Plugin */ wikitext text/x-wiki = ROV Sim = This page will go over some high level details on how our ROV simulation works, with details that will be helpful when making changes to it. Check out [https://github.com/uwrov/nautilus_sim the simulator's github repo] for instructions on how to run the simulator. == Some Quick Notes == * The sim uses meters as the primary unit * The ROV is facing the <code>-y</code> direction by default, keep this in mind when editing your model. * When panning/rotating your view in <code>gzweb</code>, the view will be centered around whatever you're clicking on. Always click on the model you want to rotate/pan around. * Pay attention to the <code>Real Time</code> and <code>Sim Time</code> readings in the top right of <code>gzweb</code> when evaluating simulation speed. If the real time is far ahead of the sim time, then the simulator is lagging. [[File:sim-axes.png|frame|How the ROV is oriented when first spawned]] == Software Used == Our simulator runs on [http://gazebosim.org/ Gazebo], a robotics simulation software often paired with ROS. Gazebo simulates a robot, its sensors, any props it might interact with, and the world everything is in. Gazebo is typically split into a number of processes: ;gzserver : Process which handles all the actual simulation. Responsible for the physics update loop and sensor data generation. ;gzclient : Commonly used QT based client program which lets us view and interact with the simulation managed by <code>gzserver</code> ;gzweb : Alternative web based client to view and interact with <code>gzserver</code>. Has less functionality and is overall more buggy than <code>gzclient</code> Our simulator uses '''gzserver''' and '''gzweb'''. We choose <code>gzweb</code> over <code>gzclient</code> because all our software is packaged in containers. It is easier to run a client over a webpage than a QT application from a container. Gazebo comes with some ROS integrations, which allow Gazebo to publish and subscribe to ROS topics. This lets us interact with the simulated ROV with the same topics we use on the real ROV. == Models == Any object simulated by gazebo is defined by a model. And a model is made of multiple links. Here are the key components of a link: ;Collision : The shape of the model. Can be either a simple shape (faster, less accurate) or a triangle mesh (more computationally expensive, more accurate). ;Visual : What the model looks like, has little impact on the speed of the simulation. ;Inertial : Mass and interias of the model. Used in calculating how the model moves. === Xacro vs URDF vs SDF === [https://newscrewdriver.com/2018/07/31/ros-notes-urdf-vs-gazebo-sdf/ Article on URDF vs SDF] ;xacro : A macro language for XML. Used to clean up our URDF files. : The '''.urdf.xacro''' file contains XML macros and instantiations of the robot model. : The '''.gazebo''' file contains information on how gazebo plugins will interact with links on the model. ;URDF : ''U''nified ''R''obot ''D''escription ''F''ormat. An XML language used by ROS to describe a single robot. ;SDF : ''S''imulation ''D''escription ''F''ormat. Another XML language used by Gazebo which describes the starting state of a simulated world. You ''could'' stick to only editing <code>.sdf</code> files, but we define our robots using <code>xacro</code>. <code>xacro</code> gives us the ability to define macros and variables in our XML, which are immensely helpful when making changes to our models. Here is the general workflow of editing a model named <code>**</code>: # Edit xacro files (ending in <code>**.urdf.xacro</code> or <code>.gazebo</code>) by hand. ## Keep variables and macro definitions/instantiations in the '''.urdf.xacro''' file. This file should also have a link to include the contents of the '''.gazebo''' file. ## Keep Gazebo specific blocks inside the '''.gazebo''' file (plugins, sensors, any special instructions Gazebo should take when converting URDF to SDF). # Verify validity of xacro file with <code>check_urdf <(xacro **.urdf.xacro)</code> # Compile the xacro file to a URDF file using <code>xacro **.urdf.xacro > **.urdf</code> # Spawn the model in a running Gazebo instance with <code>rosrun gazebo_ros spawn_model -f **.urdf -urdf -model **</code> [[File:files-compile.png|border|How all the different file types relate to one another.]] === Meshes === The simulator is able to take in a 3d model formatted in <code>.dae</code>, <code>.stl</code>, or <code>.obj</code> for collision and visual definitions of a link. '''.dae''' is the preferred format. == Plugins == Plugins add extra functionality to our simulation. There are many kinds of plugins, you can read about them [http://gazebosim.org/tutorials?tut=plugins_hello_world&cat=write_plugin here (basics)] and [http://gazebosim.org/tutorials?tut=ros_gzplugins here (some handy ROS ready ones)]. === Buoyancy Plugin === The simulator uses Gazebo's [https://gazebosim.org/tutorials?tut=hydrodynamics&cat=physics BuoyancyPlugin] to simulate the buoyant force on the ROV. === Thruster Plugin === The simulator uses a [https://github.com/uwrov/nautilus_sim/tree/main/src/nautilus_worlds/src basic model plugin] to simulate the thrusters of the ROV. Here's an outline on how the plugin works: # The source code for the plugin is compiled to a shared object <code>.so</code> file when running <code>catkin_make</code>. So any changes to the plugin require a <code>catkin_make</code> to be seen. # The shared object is connected to a link in the simulation in a <code>.gazebo</code> file. # The plugin is constructed and loaded when the model is spawned. The plugin subscribes to <code>/nautilus/thrusters/pwm</code>. # On every world update, the plugin sets the force on each of the thrusters according to the last reading of <code>/nautilus/thrusters/pwm</code> ## 6-long int arrays are constantly published to <code>/nautilus/thrusters/pwm</code>. The plugin reads these arrays and applies the PWMs onto the motors in order of A-F, which are named in the <code>.xacro.urdf</code> file. ## A PWM is converted to a force on a thruster. ### Valid PWMs lie in range <code>[1000, 2000]</code>. <code>1000</code> is max reverse thrust, <code>2000</code> is max forward thrust, and <code>1500</code> is no thrust. ### The PWMs are piecewise-linearly mapped to a thrust value, described in the table below. #### Motors A-D are T100, E and F are both T200 motors. This can be changed by modifying the <code>num_t100_</code> variable of [https://github.com/uwrov/nautilus_sim/blob/main/src/nautilus_worlds/src/thruster_manager.h#L44 <code>thruster_manager.h</code>] ### The force is converted to <code>N</code> and applied onto the corresponding thruster link. Then the ROV moves! {| class="wikitable" style="margin-left: auto; margin-right: auto;" |+Thrust Mappings (PWM to <code>kg f</code>) |- !scope="col"| PWM !scope="col"| T100 !scope="col"| T200 |- !scope="row"| [1000, 1500) | [-1.82, 0) | [-4.1, 0) |- !scope="row"| [1500, 2000] | [0, 2.36] | [0, 5.25] |} 024f24c8744afbf2eb822cc4562048709e1b6d03 325 324 2022-02-12T02:33:35Z Gunarp 7 wikitext text/x-wiki = ROV Sim = This page is meant to serve as a reference for our ROV simulator, with details that will be helpful when making changes to it. Check out [https://github.com/uwrov/nautilus_sim the simulator's github repo] for instructions on how to run the simulator. == Some Quick Notes == * The sim uses meters as the primary unit * The ROV is facing the <code>-y</code> direction by default, keep this in mind when editing your model. * When panning/rotating your view in <code>gzweb</code>, the view will be centered around whatever you're clicking on. Always click on the model you want to rotate/pan around. * Pay attention to the <code>Real Time</code> and <code>Sim Time</code> readings in the top right of <code>gzweb</code> when evaluating simulation speed. If the real time is far ahead of the sim time, then the simulator is lagging. [[File:sim-axes.png|frame|How the ROV is oriented when first spawned]] == Software Used == Our simulator runs on [http://gazebosim.org/ Gazebo], a robotics simulation software often paired with ROS. Gazebo simulates a robot, its sensors, any props it might interact with, and the world everything is in. Gazebo is typically split into a number of processes: ;gzserver : Process which handles all the actual simulation. Responsible for the physics update loop and sensor data generation. ;gzclient : Commonly used QT based client program which lets us view and interact with the simulation managed by <code>gzserver</code> ;gzweb : Alternative web based client to view and interact with <code>gzserver</code>. Has less functionality and is overall more buggy than <code>gzclient</code> Our simulator uses '''gzserver''' and '''gzweb'''. We choose <code>gzweb</code> over <code>gzclient</code> because all our software is packaged in containers. It is easier to run a client over a webpage than a QT application from a container. Gazebo comes with some ROS integrations, which allow Gazebo to publish and subscribe to ROS topics. This lets us interact with the simulated ROV with the same topics we use on the real ROV. == Models == Any object simulated by gazebo is defined by a model. And a model is made of multiple links. Here are the key components of a link: ;Collision : The shape of the model. Can be either a simple shape (faster, less accurate) or a triangle mesh (more computationally expensive, more accurate). ;Visual : What the model looks like, has little impact on the speed of the simulation. ;Inertial : Mass and interias of the model. Used in calculating how the model moves. === Xacro vs URDF vs SDF === [https://newscrewdriver.com/2018/07/31/ros-notes-urdf-vs-gazebo-sdf/ Article on URDF vs SDF] ;Xacro : A macro language for XML. Used to clean up our URDF files. : The '''.urdf.xacro''' file contains XML macros and instantiations of the robot model. : The '''.gazebo''' file contains information on how gazebo plugins will interact with links on the model. ;URDF : ''U''nified ''R''obot ''D''escription ''F''ormat. An XML language used by ROS to describe a single robot. ;SDF : ''S''imulation ''D''escription ''F''ormat. Another XML language used by Gazebo which describes the starting state of a simulated world. You ''could'' stick to only editing <code>.sdf</code> files, but we define our robots using <code>xacro</code>. <code>xacro</code> gives us the ability to define macros and variables in our XML, which are immensely helpful when making changes to our models. Here is the general workflow of editing a model named <code>**</code>: # Edit xacro files (ending in <code>**.urdf.xacro</code> or <code>.gazebo</code>) by hand. ## Keep variables and macro definitions/instantiations in the '''.urdf.xacro''' file. This file should also have a link to include the contents of the '''.gazebo''' file. ## Keep Gazebo specific blocks inside the '''.gazebo''' file (plugins, sensors, any special instructions Gazebo should take when converting URDF to SDF). # Verify validity of xacro file with <code>check_urdf <(xacro **.urdf.xacro)</code> # Compile the xacro file to a URDF file using <code>xacro **.urdf.xacro > **.urdf</code> # Spawn the model in a running Gazebo instance with <code>rosrun gazebo_ros spawn_model -f **.urdf -urdf -model **</code> [[File:files-compile.png|border|How all the different file types relate to one another.]] === Meshes === The simulator is able to take in a 3d model formatted in <code>.dae</code>, <code>.stl</code>, or <code>.obj</code> for collision and visual definitions of a link. '''.dae''' is the preferred format. Meshes are put into the <code>models</code> directory, under the corresponding model. ==== Add a new prop ==== Props are typically simple enough that you can define them in <code>sdf</code> directly. # Create a copy of the <code>duck</code> folder in the <code>models</code> directory. # Rename the folder and the <code>model.config</code> file to reflect the prop you're making. # Replace the contents of the <code>meshes</code> subdirectory and <code>model.sdf</code> with the appropriate 3d model and collision/intertial information. # Add an entry for your prop in <code>models/database.config</code>, based on the name of the folder you created. == Plugins == Plugins add extra functionality to our simulation. There are many kinds of plugins, you can read about them [http://gazebosim.org/tutorials?tut=plugins_hello_world&cat=write_plugin here (basics)] and [http://gazebosim.org/tutorials?tut=ros_gzplugins here (some handy ROS ready ones)]. === Buoyancy Plugin === The simulator uses Gazebo's [https://gazebosim.org/tutorials?tut=hydrodynamics&cat=physics BuoyancyPlugin] to simulate the buoyant force on the ROV. === Thruster Plugin === The simulator uses a [https://github.com/uwrov/nautilus_sim/tree/main/src/nautilus_worlds/src basic model plugin] to simulate the thrusters of the ROV. Here's an outline on how the plugin works: # The source code for the plugin is compiled to a shared object <code>.so</code> file when running <code>catkin_make</code>. So any changes to the plugin require a <code>catkin_make</code> to be seen. # The shared object is connected to a link in the simulation in a <code>.gazebo</code> file. # The plugin is constructed and loaded when the model is spawned. The plugin subscribes to <code>/nautilus/thrusters/pwm</code>. # On every world update, the plugin sets the force on each of the thrusters according to the last reading of <code>/nautilus/thrusters/pwm</code> ## 6-long int arrays are constantly published to <code>/nautilus/thrusters/pwm</code>. The plugin reads these arrays and applies the PWMs onto the motors in order of A-F, which are named in the <code>.xacro.urdf</code> file. ## A PWM is converted to a force on a thruster. ### Valid PWMs lie in range <code>[1000, 2000]</code>. <code>1000</code> is max reverse thrust, <code>2000</code> is max forward thrust, and <code>1500</code> is no thrust. ### The PWMs are piecewise-linearly mapped to a thrust value, described in the table below. #### Motors A-D are T100, E and F are both T200 motors. This can be changed by modifying the <code>num_t100_</code> variable of [https://github.com/uwrov/nautilus_sim/blob/main/src/nautilus_worlds/src/thruster_manager.h#L44 <code>thruster_manager.h</code>] ### The force is converted to <code>N</code> and applied onto the corresponding thruster link. Then the ROV moves! {| class="wikitable" style="margin-left: auto; margin-right: auto;" |+Thrust Mappings (PWM to <code>kg f</code>) |- !scope="col"| PWM !scope="col"| T100 !scope="col"| T200 |- !scope="row"| [1000, 1500) | [-1.82, 0) | [-4.1, 0) |- !scope="row"| [1500, 2000] | [0, 2.36] | [0, 5.25] |} 22a5c2248391b93711edc6e705fad1ce00649a54 326 325 2022-02-17T02:31:22Z Gunarp 7 /* Plugins */ wikitext text/x-wiki = ROV Sim = This page is meant to serve as a reference for our ROV simulator, with details that will be helpful when making changes to it. Check out [https://github.com/uwrov/nautilus_sim the simulator's github repo] for instructions on how to run the simulator. == Some Quick Notes == * The sim uses meters as the primary unit * The ROV is facing the <code>-y</code> direction by default, keep this in mind when editing your model. * When panning/rotating your view in <code>gzweb</code>, the view will be centered around whatever you're clicking on. Always click on the model you want to rotate/pan around. * Pay attention to the <code>Real Time</code> and <code>Sim Time</code> readings in the top right of <code>gzweb</code> when evaluating simulation speed. If the real time is far ahead of the sim time, then the simulator is lagging. [[File:sim-axes.png|frame|How the ROV is oriented when first spawned]] == Software Used == Our simulator runs on [http://gazebosim.org/ Gazebo], a robotics simulation software often paired with ROS. Gazebo simulates a robot, its sensors, any props it might interact with, and the world everything is in. Gazebo is typically split into a number of processes: ;gzserver : Process which handles all the actual simulation. Responsible for the physics update loop and sensor data generation. ;gzclient : Commonly used QT based client program which lets us view and interact with the simulation managed by <code>gzserver</code> ;gzweb : Alternative web based client to view and interact with <code>gzserver</code>. Has less functionality and is overall more buggy than <code>gzclient</code> Our simulator uses '''gzserver''' and '''gzweb'''. We choose <code>gzweb</code> over <code>gzclient</code> because all our software is packaged in containers. It is easier to run a client over a webpage than a QT application from a container. Gazebo comes with some ROS integrations, which allow Gazebo to publish and subscribe to ROS topics. This lets us interact with the simulated ROV with the same topics we use on the real ROV. == Models == Any object simulated by gazebo is defined by a model. And a model is made of multiple links. Here are the key components of a link: ;Collision : The shape of the model. Can be either a simple shape (faster, less accurate) or a triangle mesh (more computationally expensive, more accurate). ;Visual : What the model looks like, has little impact on the speed of the simulation. ;Inertial : Mass and interias of the model. Used in calculating how the model moves. === Xacro vs URDF vs SDF === [https://newscrewdriver.com/2018/07/31/ros-notes-urdf-vs-gazebo-sdf/ Article on URDF vs SDF] ;Xacro : A macro language for XML. Used to clean up our URDF files. : The '''.urdf.xacro''' file contains XML macros and instantiations of the robot model. : The '''.gazebo''' file contains information on how gazebo plugins will interact with links on the model. ;URDF : ''U''nified ''R''obot ''D''escription ''F''ormat. An XML language used by ROS to describe a single robot. ;SDF : ''S''imulation ''D''escription ''F''ormat. Another XML language used by Gazebo which describes the starting state of a simulated world. You ''could'' stick to only editing <code>.sdf</code> files, but we define our robots using <code>xacro</code>. <code>xacro</code> gives us the ability to define macros and variables in our XML, which are immensely helpful when making changes to our models. Here is the general workflow of editing a model named <code>**</code>: # Edit xacro files (ending in <code>**.urdf.xacro</code> or <code>.gazebo</code>) by hand. ## Keep variables and macro definitions/instantiations in the '''.urdf.xacro''' file. This file should also have a link to include the contents of the '''.gazebo''' file. ## Keep Gazebo specific blocks inside the '''.gazebo''' file (plugins, sensors, any special instructions Gazebo should take when converting URDF to SDF). # Verify validity of xacro file with <code>check_urdf <(xacro **.urdf.xacro)</code> # Compile the xacro file to a URDF file using <code>xacro **.urdf.xacro > **.urdf</code> # Spawn the model in a running Gazebo instance with <code>rosrun gazebo_ros spawn_model -f **.urdf -urdf -model **</code> [[File:files-compile.png|border|How all the different file types relate to one another.]] === Meshes === The simulator is able to take in a 3d model formatted in <code>.dae</code>, <code>.stl</code>, or <code>.obj</code> for collision and visual definitions of a link. '''.dae''' is the preferred format. Meshes are put into the <code>models</code> directory, under the corresponding model. ==== Add a new prop ==== Props are typically simple enough that you can define them in <code>sdf</code> directly. # Create a copy of the <code>duck</code> folder in the <code>models</code> directory. # Rename the folder and the <code>model.config</code> file to reflect the prop you're making. # Replace the contents of the <code>meshes</code> subdirectory and <code>model.sdf</code> with the appropriate 3d model and collision/intertial information. # Add an entry for your prop in <code>models/database.config</code>, based on the name of the folder you created. == Plugins == Plugins add extra functionality to our simulation. There are many kinds of plugins, you can read about them [http://gazebosim.org/tutorials?tut=plugins_hello_world&cat=write_plugin here (basics)] and [http://gazebosim.org/tutorials?tut=ros_gzplugins here (some handy ROS ready ones)]. === Buoyancy Plugin === The simulator uses Gazebo's [https://gazebosim.org/tutorials?tut=hydrodynamics&cat=physics BuoyancyPlugin] to simulate the buoyant force on the ROV. === Thruster Plugin === The simulator uses a [https://github.com/uwrov/nautilus_sim/tree/main/src/nautilus_worlds/src basic model plugin] to simulate the thrusters of the ROV. Here's an outline on how the plugin works: # The source code for the plugin is compiled to a shared object <code>.so</code> file when running <code>catkin_make</code>. So any changes to the plugin require a <code>catkin_make</code> to be seen. # The shared object is connected to a link in the simulation in a <code>.gazebo</code> file. # The plugin is constructed and loaded when the model is spawned. The plugin subscribes to <code>/nautilus/thrusters/pwm</code>. # On every world update, the plugin sets the force on each of the thrusters according to the last reading of <code>/nautilus/thrusters/pwm</code> ## 6-long int arrays are constantly published to <code>/nautilus/thrusters/pwm</code>. The plugin reads these arrays and applies the PWMs onto the motors in order of A-F, which are named in the <code>.xacro.urdf</code> file. ## A PWM is converted to a force on a thruster. ### Valid PWMs lie in range <code>[1000, 2000]</code>. <code>1000</code> is max reverse thrust, <code>2000</code> is max forward thrust, and <code>1500</code> is no thrust. ### The PWMs are piecewise-linearly mapped to a thrust value, described in the table below. #### Motors A-D are [https://web.archive.org/web/20171031230319/http://docs.bluerobotics.com/thrusters T100], E and F are both [https://bluerobotics.com/store/thrusters/t100-t200-thrusters/t200-thruster-r2-rp/ T200] motors. This can be changed by modifying the <code>num_t100_</code> variable of [https://github.com/uwrov/nautilus_sim/blob/main/src/nautilus_worlds/src/thruster_manager.h#L44 <code>thruster_manager.h</code>] ### The force is converted to <code>N</code> and applied onto the corresponding thruster link. Then the ROV moves! {| class="wikitable" style="margin-left: auto; margin-right: auto;" |+Thrust Mappings (PWM to <code>kg f</code>) |- !scope="col"| PWM !scope="col"| T100 !scope="col"| T200 |- !scope="row"| [1000, 1500) | [-1.82, 0) | [-4.1, 0) |- !scope="row"| [1500, 2000] | [0, 2.36] | [0, 5.25] |} b1daaae7ebf452c9af0a464bae51a89b49ade1e5 327 326 2022-02-17T02:38:31Z Gunarp 7 wikitext text/x-wiki = ROV Sim = This page is meant to serve as a reference for our ROV simulator, with details that will be helpful when making changes to it. Check out [https://github.com/uwrov/nautilus_sim the simulator's github repo] for instructions on how to run the simulator. == Some Quick Notes == * The sim uses meters as the primary unit * The ROV is facing the <code>-y</code> direction by default, keep this in mind when editing your model. * When panning/rotating your view in <code>gzweb</code>, the view will be centered around whatever you're clicking on. Always click on the model you want to rotate/pan around. * Pay attention to the <code>Real Time</code> and <code>Sim Time</code> readings in the top right of <code>gzweb</code> when evaluating simulation speed. If the real time is far ahead of the sim time, then the simulator is lagging. [[File:sim-axes.png|frame|How the ROV is oriented when first spawned]] == Software Used == Our simulator runs on [http://gazebosim.org/ Gazebo], a robotics simulation software often paired with ROS. Gazebo simulates a robot, its sensors, any props it might interact with, and the world everything is in. Gazebo is typically split into a number of processes: ;gzserver : Process which handles all the actual simulation. Responsible for the physics update loop and sensor data generation. ;gzclient : Commonly used QT based client program which lets us view and interact with the simulation managed by <code>gzserver</code> ;gzweb : Alternative web based client to view and interact with <code>gzserver</code>. Has less functionality and is overall more buggy than <code>gzclient</code> Our simulator uses '''gzserver''' and '''gzweb'''. We choose <code>gzweb</code> over <code>gzclient</code> because all our software is packaged in containers. It is easier to run a client over a webpage than a QT application from a container. Gazebo comes with some ROS integrations, which allow Gazebo to publish and subscribe to ROS topics. This lets us interact with the simulated ROV with the same topics we use on the real ROV. == Models == Any object simulated by gazebo is defined by a model. And a model is made of multiple links. Here are the key components of a link: ;Collision : The shape of the model. Can be either a simple shape (faster, less accurate) or a triangle mesh (more computationally expensive, more accurate). ;Visual : What the model looks like, has little impact on the speed of the simulation. ;Inertial : Mass and interias of the model. Used in calculating how the model moves. === Xacro vs URDF vs SDF === [https://newscrewdriver.com/2018/07/31/ros-notes-urdf-vs-gazebo-sdf/ Article on URDF vs SDF] ;Xacro : A macro language for XML. Used to clean up our URDF files. : The '''.urdf.xacro''' file contains XML macros and instantiations of the robot model. : The '''.gazebo''' file contains information on how gazebo plugins will interact with links on the model. ;URDF : ''U''nified ''R''obot ''D''escription ''F''ormat. An XML language used by ROS to describe a single robot. ;SDF : ''S''imulation ''D''escription ''F''ormat. Another XML language used by Gazebo which describes the starting state of a simulated world. You ''could'' stick to only editing <code>.sdf</code> files, but we define our robots using <code>xacro</code>. <code>xacro</code> gives us the ability to define macros and variables in our XML, which are immensely helpful when making changes to our models. Here is the general workflow of editing a model named <code>**</code>: # Edit xacro files (ending in <code>**.urdf.xacro</code> or <code>.gazebo</code>) by hand. ## Keep variables and macro definitions/instantiations in the '''.urdf.xacro''' file. This file should also have a link to include the contents of the '''.gazebo''' file. ## Keep Gazebo specific blocks inside the '''.gazebo''' file (plugins, sensors, any special instructions Gazebo should take when converting URDF to SDF). # Verify validity of xacro file with <code>check_urdf <(xacro **.urdf.xacro)</code> # Compile the xacro file to a URDF file using <code>xacro **.urdf.xacro > **.urdf</code> # Spawn the model in a running Gazebo instance with <code>rosrun gazebo_ros spawn_model -f **.urdf -urdf -model **</code> [[File:files-compile.png|border|How all the different file types relate to one another.]] === Meshes === The simulator is able to take in a 3d model formatted in <code>.dae</code>, <code>.stl</code>, or <code>.obj</code> for collision and visual definitions of a link. '''.dae''' is the preferred format. Meshes are put into the <code>models</code> directory, under the corresponding model. ==== Add a new prop ==== Props are typically simple enough that you can define them in <code>sdf</code> directly. # Create a copy of the <code>duck</code> folder in the <code>models</code> directory. # Rename the folder and the <code>model.config</code> file to reflect the prop you're making. # Replace the contents of the <code>meshes</code> subdirectory and <code>model.sdf</code> with the appropriate 3d model and collision/intertial information. # Add an entry for your prop in <code>models/database.config</code>, based on the name of the folder you created. == Plugins == Plugins add extra functionality to our simulation. There are many kinds of plugins, you can read about them [http://gazebosim.org/tutorials?tut=plugins_hello_world&cat=write_plugin here (basics)] and [http://gazebosim.org/tutorials?tut=ros_gzplugins here (some handy ROS ready ones)]. === Buoyancy Plugin === The simulator uses Gazebo's [https://gazebosim.org/tutorials?tut=hydrodynamics&cat=physics BuoyancyPlugin] to simulate the buoyant force on the ROV. === Thruster Plugin === The simulator uses a [https://github.com/uwrov/nautilus_sim/tree/main/src/nautilus_worlds/src basic model plugin] to simulate the thrusters of the ROV. Here's an outline on how the plugin works: # The source code for the plugin is compiled to a shared object <code>.so</code> file when running <code>catkin_make</code>. So any changes to the plugin require a <code>catkin_make</code> to be seen. # The shared object is connected to a link in the simulation in a <code>.gazebo</code> file. # The plugin is constructed and loaded when the model is spawned. The plugin subscribes to <code>/nautilus/thrusters/pwm</code>. # On every world update, the plugin sets the force on each of the thrusters according to the last reading of <code>/nautilus/thrusters/pwm</code> ## 6-long int arrays are constantly published to <code>/nautilus/thrusters/pwm</code>. The plugin reads these arrays and applies the PWMs onto the motors in order of A-F, which are named in the <code>.xacro.urdf</code> file. ## A PWM is converted to a force on a thruster. ### Valid PWMs lie in range <code>[1100, 1900]</code>. <code>1100</code> is max reverse thrust, <code>1900</code> is max forward thrust, and <code>1500</code> is no thrust. ### The PWMs are piecewise-linearly mapped to a thrust value, described in the table below. #### Motors A-D are [https://web.archive.org/web/20171031230319/http://docs.bluerobotics.com/thrusters T100], E and F are both [https://bluerobotics.com/store/thrusters/t100-t200-thrusters/t200-thruster-r2-rp/ T200] motors. This can be changed by modifying the <code>num_t100_</code> variable of [https://github.com/uwrov/nautilus_sim/blob/main/src/nautilus_worlds/src/thruster_manager.h#L44 <code>thruster_manager.h</code>] ### The force is converted to <code>N</code> and applied onto the corresponding thruster link. Then the ROV moves! {| class="wikitable" style="margin-left: auto; margin-right: auto;" |+Thrust Mappings (PWM to <code>kg f</code>) |- !scope="col"| PWM !scope="col"| T100 !scope="col"| T200 |- !scope="row"| [1000, 1475) | [-1.82, 0) | [-4.1, 0) |- !scope="row"| [1475, 1525) | [0, 0) | [0, 0) |- !scope="row"| [1525, 2000] | [0, 2.36] | [0, 5.25] |} b027b182c36a3afaa854f65eec0982a87441e506 328 327 2022-02-17T02:38:45Z Gunarp 7 wikitext text/x-wiki = ROV Sim = This page is meant to serve as a reference for our ROV simulator, with details that will be helpful when making changes to it. Check out [https://github.com/uwrov/nautilus_sim the simulator's github repo] for instructions on how to run the simulator. == Some Quick Notes == * The sim uses meters as the primary unit * The ROV is facing the <code>-y</code> direction by default, keep this in mind when editing your model. * When panning/rotating your view in <code>gzweb</code>, the view will be centered around whatever you're clicking on. Always click on the model you want to rotate/pan around. * Pay attention to the <code>Real Time</code> and <code>Sim Time</code> readings in the top right of <code>gzweb</code> when evaluating simulation speed. If the real time is far ahead of the sim time, then the simulator is lagging. [[File:sim-axes.png|frame|How the ROV is oriented when first spawned]] == Software Used == Our simulator runs on [http://gazebosim.org/ Gazebo], a robotics simulation software often paired with ROS. Gazebo simulates a robot, its sensors, any props it might interact with, and the world everything is in. Gazebo is typically split into a number of processes: ;gzserver : Process which handles all the actual simulation. Responsible for the physics update loop and sensor data generation. ;gzclient : Commonly used QT based client program which lets us view and interact with the simulation managed by <code>gzserver</code> ;gzweb : Alternative web based client to view and interact with <code>gzserver</code>. Has less functionality and is overall more buggy than <code>gzclient</code> Our simulator uses '''gzserver''' and '''gzweb'''. We choose <code>gzweb</code> over <code>gzclient</code> because all our software is packaged in containers. It is easier to run a client over a webpage than a QT application from a container. Gazebo comes with some ROS integrations, which allow Gazebo to publish and subscribe to ROS topics. This lets us interact with the simulated ROV with the same topics we use on the real ROV. == Models == Any object simulated by gazebo is defined by a model. And a model is made of multiple links. Here are the key components of a link: ;Collision : The shape of the model. Can be either a simple shape (faster, less accurate) or a triangle mesh (more computationally expensive, more accurate). ;Visual : What the model looks like, has little impact on the speed of the simulation. ;Inertial : Mass and interias of the model. Used in calculating how the model moves. === Xacro vs URDF vs SDF === [https://newscrewdriver.com/2018/07/31/ros-notes-urdf-vs-gazebo-sdf/ Article on URDF vs SDF] ;Xacro : A macro language for XML. Used to clean up our URDF files. : The '''.urdf.xacro''' file contains XML macros and instantiations of the robot model. : The '''.gazebo''' file contains information on how gazebo plugins will interact with links on the model. ;URDF : ''U''nified ''R''obot ''D''escription ''F''ormat. An XML language used by ROS to describe a single robot. ;SDF : ''S''imulation ''D''escription ''F''ormat. Another XML language used by Gazebo which describes the starting state of a simulated world. You ''could'' stick to only editing <code>.sdf</code> files, but we define our robots using <code>xacro</code>. <code>xacro</code> gives us the ability to define macros and variables in our XML, which are immensely helpful when making changes to our models. Here is the general workflow of editing a model named <code>**</code>: # Edit xacro files (ending in <code>**.urdf.xacro</code> or <code>.gazebo</code>) by hand. ## Keep variables and macro definitions/instantiations in the '''.urdf.xacro''' file. This file should also have a link to include the contents of the '''.gazebo''' file. ## Keep Gazebo specific blocks inside the '''.gazebo''' file (plugins, sensors, any special instructions Gazebo should take when converting URDF to SDF). # Verify validity of xacro file with <code>check_urdf <(xacro **.urdf.xacro)</code> # Compile the xacro file to a URDF file using <code>xacro **.urdf.xacro > **.urdf</code> # Spawn the model in a running Gazebo instance with <code>rosrun gazebo_ros spawn_model -f **.urdf -urdf -model **</code> [[File:files-compile.png|border|How all the different file types relate to one another.]] === Meshes === The simulator is able to take in a 3d model formatted in <code>.dae</code>, <code>.stl</code>, or <code>.obj</code> for collision and visual definitions of a link. '''.dae''' is the preferred format. Meshes are put into the <code>models</code> directory, under the corresponding model. ==== Add a new prop ==== Props are typically simple enough that you can define them in <code>sdf</code> directly. # Create a copy of the <code>duck</code> folder in the <code>models</code> directory. # Rename the folder and the <code>model.config</code> file to reflect the prop you're making. # Replace the contents of the <code>meshes</code> subdirectory and <code>model.sdf</code> with the appropriate 3d model and collision/intertial information. # Add an entry for your prop in <code>models/database.config</code>, based on the name of the folder you created. == Plugins == Plugins add extra functionality to our simulation. There are many kinds of plugins, you can read about them [http://gazebosim.org/tutorials?tut=plugins_hello_world&cat=write_plugin here (basics)] and [http://gazebosim.org/tutorials?tut=ros_gzplugins here (some handy ROS ready ones)]. === Buoyancy Plugin === The simulator uses Gazebo's [https://gazebosim.org/tutorials?tut=hydrodynamics&cat=physics BuoyancyPlugin] to simulate the buoyant force on the ROV. === Thruster Plugin === The simulator uses a [https://github.com/uwrov/nautilus_sim/tree/main/src/nautilus_worlds/src basic model plugin] to simulate the thrusters of the ROV. Here's an outline on how the plugin works: # The source code for the plugin is compiled to a shared object <code>.so</code> file when running <code>catkin_make</code>. So any changes to the plugin require a <code>catkin_make</code> to be seen. # The shared object is connected to a link in the simulation in a <code>.gazebo</code> file. # The plugin is constructed and loaded when the model is spawned. The plugin subscribes to <code>/nautilus/thrusters/pwm</code>. # On every world update, the plugin sets the force on each of the thrusters according to the last reading of <code>/nautilus/thrusters/pwm</code> ## 6-long int arrays are constantly published to <code>/nautilus/thrusters/pwm</code>. The plugin reads these arrays and applies the PWMs onto the motors in order of A-F, which are named in the <code>.xacro.urdf</code> file. ## A PWM is converted to a force on a thruster. ### Valid PWMs lie in range <code>[1100, 1900]</code>. <code>1100</code> is max reverse thrust, <code>1900</code> is max forward thrust, and <code>1500</code> is no thrust. ### The PWMs are piecewise-linearly mapped to a thrust value, described in the table below. #### Motors A-D are [https://web.archive.org/web/20171031230319/http://docs.bluerobotics.com/thrusters T100], E and F are both [https://bluerobotics.com/store/thrusters/t100-t200-thrusters/t200-thruster-r2-rp/ T200] motors. This can be changed by modifying the <code>num_t100_</code> variable of [https://github.com/uwrov/nautilus_sim/blob/main/src/nautilus_worlds/src/thruster_manager.h#L44 <code>thruster_manager.h</code>] ### The force is converted to <code>N</code> and applied onto the corresponding thruster link. Then the ROV moves! {| class="wikitable" style="margin-left: auto; margin-right: auto;" |+Thrust Mappings (PWM to <code>kg f</code>) |- !scope="col"| PWM !scope="col"| T100 !scope="col"| T200 |- !scope="row"| [1100, 1475) | [-1.82, 0) | [-4.1, 0) |- !scope="row"| [1475, 1525) | [0, 0) | [0, 0) |- !scope="row"| [1525, 1900] | [0, 2.36] | [0, 5.25] |} cd3e6a9921a3b2573f13ecac6749b145b61e0fef 6 49 322 2022-02-12T00:49:12Z Gunarp 7 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 1 329 267 2022-02-23T02:20:46Z Alnis S 6 /* Welcome to {{SITENAME}}! */ wikitext text/x-wiki __NOTOC__ == Welcome to {{SITENAME}}! == Welcome to the UWROV wiki! Check out our subteam wiki areas: * [[Software]] * [[Mechanical]] Project page for our 2022 MATE ROV: [[ROV22]] Summary of this year's challenge: [[2022 MATE EXPLORER Challenge]] === Contributing to the Wiki === * <span class="plainlinks">[[mw:Special:MyLanguage/Help:Contents|MediaWiki guide (e.g. navigation, editing, deleting pages, blocking users)]] * [[meta:FAQ|Miraheze FAQ]] * [[meta:Request features|Request settings changes on your wiki. (Extensions and Logo/Favicon changes should be done through Special:ManageWiki on your wiki]]. 330d7b7785d928b2aa8fa27fca382413df575386 330 329 2022-02-23T02:21:48Z Alnis S 6 /* Welcome to {{SITENAME}}! */ wikitext text/x-wiki __NOTOC__ == Welcome to {{SITENAME}}! == Welcome to the UWROV wiki! Check out our subteam wiki areas: * [[Software]] * [[Mechanical]] Project page for our 2022 MATE ROV: [[ROV22]] Summary of this year's challenge: [[2022 MATE EXPLORER Tasks]] === Contributing to the Wiki === * <span class="plainlinks">[[mw:Special:MyLanguage/Help:Contents|MediaWiki guide (e.g. navigation, editing, deleting pages, blocking users)]] * [[meta:FAQ|Miraheze FAQ]] * [[meta:Request features|Request settings changes on your wiki. (Extensions and Logo/Favicon changes should be done through Special:ManageWiki on your wiki]]. 303087df165d0dfd05e139e70af730dcee757833 0 50 331 2022-02-23T02:23:31Z Alnis S 6 Created page with "== Task 1: Marine Renewable Energy == == Task 2: Offshore Aquaculture and Blue Carbon == == Task 3: Antarctica Then and Now -- Endurance22 and MATE Floats! ==" wikitext text/x-wiki == Task 1: Marine Renewable Energy == == Task 2: Offshore Aquaculture and Blue Carbon == == Task 3: Antarctica Then and Now -- Endurance22 and MATE Floats! == c7b90a54a44a5edb6fef6fd716ec676d82fc2362 332 331 2022-02-23T02:33:11Z Alnis S 6 /* Task 3: Antarctica Then and Now -- Endurance22 and MATE Floats! */ wikitext text/x-wiki == Task 1: Marine Renewable Energy == == Task 2: Offshore Aquaculture and Blue Carbon == == Task 3: Antarctica Then and Now – Endurance22 and MATE Floats! == === 3.1 MATE Floats! === ==== Scoring Summary: 50 pts total ==== * Recovering a GO-BGC float ** ''5 pts'': determining location where float will next surface ** ''10 pts'': recovering the float * Designing and constructing a float ** ''5 pts'': building a float before the competition ** ''5 pts'': deploying the float in the designated area ** ''25 pts'': completing two vertical profiles (15 pts if only one completed) === 3.2 Endurance22 === ==== Scoring Summary: 50 pts total ==== * Finding and mapping the ''Endurance'' ** ''10 pts'': flying a transect over the wreck area ** ''5 pts'': mapping the wreck * Photomosaic of the wreck ** ''5 pts'': images of all sections ** ''20 pts'': autonomous photomosaic creation (10 pts if done manually) * Measuring length of the wreck from bow to stern ** ''10 pts'': within 10 cm of true value (5 pts if 10 cm < error < 20 cm, 0 pts otherwise) b380dc8ad153040d70197a8e7c031acd64f0ccce 333 332 2022-02-23T02:33:13Z Ronankau 34 /* Task 1: Marine Renewable Energy */ wikitext text/x-wiki == Task 1: Marine Renewable Energy == ===1.1 Replace damaged section of power cable=== == Task 2: Offshore Aquaculture and Blue Carbon == == Task 3: Antarctica Then and Now – Endurance22 and MATE Floats! == === 3.1 MATE Floats! === ==== Scoring Summary: 50 pts total ==== * Recovering a GO-BGC float ** ''5 pts'': determining location where float will next surface ** ''10 pts'': recovering the float * Designing and constructing a float ** ''5 pts'': building a float before the competition ** ''5 pts'': deploying the float in the designated area ** ''25 pts'': completing two vertical profiles (15 pts if only one completed) === 3.2 Endurance22 === ==== Scoring Summary: 50 pts total ==== * Finding and mapping the ''Endurance'' ** ''10 pts'': flying a transect over the wreck area ** ''5 pts'': mapping the wreck * Photomosaic of the wreck ** ''5 pts'': images of all sections ** ''20 pts'': autonomous photomosaic creation (10 pts if done manually) * Measuring length of the wreck from bow to stern ** ''10 pts'': within 10 cm of true value (5 pts if 10 cm < error < 20 cm, 0 pts otherwise) 87c78128e6d982edc00950cd9e7689529b0b516e 334 333 2022-02-23T02:37:13Z Alnis S 6 /* 3.1 MATE Floats! */ wikitext text/x-wiki == Task 1: Marine Renewable Energy == ===1.1 Replace damaged section of power cable=== == Task 2: Offshore Aquaculture and Blue Carbon == == Task 3: Antarctica Then and Now – Endurance22 and MATE Floats! == === 3.1 MATE Floats! === ==== Scoring Summary: 50 pts total ==== * Recovering a GO-BGC float ** ''5 pts'': determining location where float will next surface ** ''10 pts'': recovering the float * Designing and constructing a float ** ''5 pts'': building a float before the competition ** ''5 pts'': deploying the float in the designated area ** ''25 pts'': completing two vertical profiles (15 pts if only one completed) === Determining Float Surfacing Location === Onshore task === 3.2 Endurance22 === ==== Scoring Summary: 50 pts total ==== * Finding and mapping the ''Endurance'' ** ''10 pts'': flying a transect over the wreck area ** ''5 pts'': mapping the wreck * Photomosaic of the wreck ** ''5 pts'': images of all sections ** ''20 pts'': autonomous photomosaic creation (10 pts if done manually) * Measuring length of the wreck from bow to stern ** ''10 pts'': within 10 cm of true value (5 pts if 10 cm < error < 20 cm, 0 pts otherwise) f74d3a615439e600e7a91de26caf0a1b4bbe9b7a 335 334 2022-02-23T02:53:49Z Alnis S 6 wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!Subtask!!Points!!class="unsortable"|Description!!Categories |- | rowspan="2"|1.1 Replacing damaged power cable | Visual inspection of cable | 5 | TODO | TODO |- | Cutting cable on both sides of the damaged section | 10 | TODO | TODO |- |} == Task 1: Marine Renewable Energy == ===1.1 Replace damaged section of power cable=== == Task 2: Offshore Aquaculture and Blue Carbon == == Task 3: Antarctica Then and Now – Endurance22 and MATE Floats! == === 3.1 MATE Floats! === ==== Scoring Summary: 50 pts total ==== * Recovering a GO-BGC float ** ''5 pts'': determining location where float will next surface ** ''10 pts'': recovering the float * Designing and constructing a float ** ''5 pts'': building a float before the competition ** ''5 pts'': deploying the float in the designated area ** ''25 pts'': completing two vertical profiles (15 pts if only one completed) === Determining Float Surfacing Location === Onshore task === 3.2 Endurance22 === ==== Scoring Summary: 50 pts total ==== * Finding and mapping the ''Endurance'' ** ''10 pts'': flying a transect over the wreck area ** ''5 pts'': mapping the wreck * Photomosaic of the wreck ** ''5 pts'': images of all sections ** ''20 pts'': autonomous photomosaic creation (10 pts if done manually) * Measuring length of the wreck from bow to stern ** ''10 pts'': within 10 cm of true value (5 pts if 10 cm < error < 20 cm, 0 pts otherwise) 6deb20d4adf81e2e47918524f443cdd9a1c06bbb 336 335 2022-02-23T03:04:18Z Alnis S 6 wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!Subtask!!Points!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 5 | TODO | TODO |- | Cutting cable | 10 | TODO | TODO |- | Removing damaged cable | 5 | TODO | TODO |- | Installing new cable | 10 | TODO | TODO |- | Securing new cable | 10 | TODO | TODO |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | 5 | TODO | TODO |- | Recovering old module | 5 | TODO | TODO |- | Attaching new module | 5 | TODO | TODO |- | Securing new module clamp | 5 | TODO | TODO |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | 5 | TODO | TODO |- | Recover hydrophone | 5 | TODO | TODO |- | Pull ghost net pin | 10 | TODO | TODO |- | Remove ghost net from water | 5 | TODO | TODO |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | 15 | Only 5 points if done manually TODO | TODO |} == Task 1: Marine Renewable Energy == ===1.1 Replace damaged section of power cable=== == Task 2: Offshore Aquaculture and Blue Carbon == == Task 3: Antarctica Then and Now – Endurance22 and MATE Floats! == === 3.1 MATE Floats! === ==== Scoring Summary: 50 pts total ==== * Recovering a GO-BGC float ** ''5 pts'': determining location where float will next surface ** ''10 pts'': recovering the float * Designing and constructing a float ** ''5 pts'': building a float before the competition ** ''5 pts'': deploying the float in the designated area ** ''25 pts'': completing two vertical profiles (15 pts if only one completed) === Determining Float Surfacing Location === Onshore task === 3.2 Endurance22 === ==== Scoring Summary: 50 pts total ==== * Finding and mapping the ''Endurance'' ** ''10 pts'': flying a transect over the wreck area ** ''5 pts'': mapping the wreck * Photomosaic of the wreck ** ''5 pts'': images of all sections ** ''20 pts'': autonomous photomosaic creation (10 pts if done manually) * Measuring length of the wreck from bow to stern ** ''10 pts'': within 10 cm of true value (5 pts if 10 cm < error < 20 cm, 0 pts otherwise) 88b7bc4eda3d1766105be600695026cd56e8a750 337 336 2022-02-23T03:15:46Z Alnis S 6 /* Table of Tasks */ wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!Subtask!!Points!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 5 | TODO | TODO |- | Cutting cable | 10 | TODO | TODO |- | Removing damaged cable | 5 | TODO | TODO |- | Installing new cable | 10 | TODO | TODO |- | Securing new cable | 10 | TODO | TODO |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | 5 | TODO | TODO |- | Recovering old module | 5 | TODO | TODO |- | Attaching new module | 5 | TODO | TODO |- | Securing new module clamp | 5 | TODO | TODO |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | 5 | TODO | TODO |- | Recover hydrophone | 5 | TODO | TODO |- | Pull ghost net pin | 10 | TODO | TODO |- | Remove ghost net from water | 5 | TODO | TODO |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | 15 | Only 5 points if done manually TODO | TODO |- | rowspan="5"|2.1 Inspecting fish pen | Autonomous transect/inspection | 25 | 10 points if done manually TODO | TODO |- | Identifying damaged net areas | 5 | TODO | TODO |- | Repairing damaged net area | 10 | TODO | TODO |- | Removing encrusting marine growth | 5 | TODO | TODO |- | Removing algal marine growth | 5 | TODO | TODO |- | rowspan="3"|2.2 Maintaining a healthy environment | AI identification of "morts" | 10 | TODO | TODO |- | Collecting a "mort" | 5 | TODO | TODO |- | Putting "mort" in collection tube | 5 | TODO | TODO |- | rowspan="2"|2.3 Measure fish size | Determine average fish size | 15 | Must be within 2 cm TODO | TODO |- | Determine biomass of fish | 5 | TODO | TODO |- | rowspan="2"|2.4 Farm seagrass | Prune existing seagrass | 5 | TODO | TODO |- | Plant new seagrass | 5 | TODO | TODO |} == Task 1: Marine Renewable Energy == ===1.1 Replace damaged section of power cable=== == Task 2: Offshore Aquaculture and Blue Carbon == == Task 3: Antarctica Then and Now – Endurance22 and MATE Floats! == === 3.1 MATE Floats! === ==== Scoring Summary: 50 pts total ==== * Recovering a GO-BGC float ** ''5 pts'': determining location where float will next surface ** ''10 pts'': recovering the float * Designing and constructing a float ** ''5 pts'': building a float before the competition ** ''5 pts'': deploying the float in the designated area ** ''25 pts'': completing two vertical profiles (15 pts if only one completed) === Determining Float Surfacing Location === Onshore task === 3.2 Endurance22 === ==== Scoring Summary: 50 pts total ==== * Finding and mapping the ''Endurance'' ** ''10 pts'': flying a transect over the wreck area ** ''5 pts'': mapping the wreck * Photomosaic of the wreck ** ''5 pts'': images of all sections ** ''20 pts'': autonomous photomosaic creation (10 pts if done manually) * Measuring length of the wreck from bow to stern ** ''10 pts'': within 10 cm of true value (5 pts if 10 cm < error < 20 cm, 0 pts otherwise) 3d2021497bc94f42ab1bc7f1dafdcfc24573d085 338 337 2022-02-23T03:22:27Z Alnis S 6 wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!Subtask!!Points!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 5 | TODO | TODO |- | Cutting cable | 10 | TODO | TODO |- | Removing damaged cable | 5 | TODO | TODO |- | Installing new cable | 10 | TODO | TODO |- | Securing new cable | 10 | TODO | TODO |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | 5 | TODO | TODO |- | Recovering old module | 5 | TODO | TODO |- | Attaching new module | 5 | TODO | TODO |- | Securing new module clamp | 5 | TODO | TODO |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | 5 | TODO | TODO |- | Recover hydrophone | 5 | TODO | TODO |- | Pull ghost net pin | 10 | TODO | TODO |- | Remove ghost net from water | 5 | TODO | TODO |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | 15 | Only 5 points if done manually TODO | TODO |- | rowspan="5"|2.1 Inspecting fish pen | Autonomous transect/inspection | 25 | 10 points if done manually TODO | TODO |- | Identifying damaged net areas | 5 | TODO | TODO |- | Repairing damaged net area | 10 | TODO | TODO |- | Removing encrusting marine growth | 5 | TODO | TODO |- | Removing algal marine growth | 5 | TODO | TODO |- | rowspan="3"|2.2 Maintaining a healthy environment | AI identification of "morts" | 10 | TODO | TODO |- | Collecting a "mort" | 5 | TODO | TODO |- | Putting "mort" in collection tube | 5 | TODO | TODO |- | rowspan="2"|2.3 Measure fish size | Determine average fish size | 15 | Must be within 2 cm TODO | TODO |- | Determine biomass of fish | 5 | TODO | TODO |- | rowspan="2"|2.4 Farm seagrass | Prune existing seagrass | 5 | TODO | TODO |- | Plant new seagrass | 5 | TODO | TODO |- | rowspan="5"|3.1 MATE Floats! | Determine GO-BGC surfacing location | 5 | TODO | TODO |- | Recover GO-BGC float | 10 | TODO | TODO |- | Build float before competition | 5 | TODO | TODO |- | Deploy float in designated area | 5 | TODO | TODO |- | Float completes two profiles | 25 | 15 points if only one profile TODO | TODO |- | rowspan="5"|2.2 Endurance22 | Fly transect over wreck | 10 | TODO | TODO |- | Map wreck (by hand) | 5 | TODO | TODO |- | Collect images of all wreck sections | 5 | TODO | TODO |- | Autonomous photomosaic of wreck | 20 | Only 10 points if done manually | TODO |- | Measure length of wreck (error < 10 cm) | 10 | Only 5 points if 10 cm < error < 20 cm, 0 points otherwise. TODO | TODO |} == Task 1: Marine Renewable Energy == ===1.1 Replace damaged section of power cable=== == Task 2: Offshore Aquaculture and Blue Carbon == == Task 3: Antarctica Then and Now – Endurance22 and MATE Floats! == === 3.1 MATE Floats! === ==== Scoring Summary: 50 pts total ==== * Recovering a GO-BGC float ** ''5 pts'': determining location where float will next surface ** ''10 pts'': recovering the float * Designing and constructing a float ** ''5 pts'': building a float before the competition ** ''5 pts'': deploying the float in the designated area ** ''25 pts'': completing two vertical profiles (15 pts if only one completed) === Determining Float Surfacing Location === Onshore task === 3.2 Endurance22 === ==== Scoring Summary: 50 pts total ==== * Finding and mapping the ''Endurance'' ** ''10 pts'': flying a transect over the wreck area ** ''5 pts'': mapping the wreck * Photomosaic of the wreck ** ''5 pts'': images of all sections ** ''20 pts'': autonomous photomosaic creation (10 pts if done manually) * Measuring length of the wreck from bow to stern ** ''10 pts'': within 10 cm of true value (5 pts if 10 cm < error < 20 cm, 0 pts otherwise) 07e60e4084299621b76447b3c5fb6f58bb340e77 339 338 2022-02-23T22:01:55Z Alnis S 6 Remove old format information wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!Subtask!!Points!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 5 | TODO | TODO |- | Cutting cable | 10 | TODO | TODO |- | Removing damaged cable | 5 | TODO | TODO |- | Installing new cable | 10 | TODO | TODO |- | Securing new cable | 10 | TODO | TODO |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | 5 | TODO | TODO |- | Recovering old module | 5 | TODO | TODO |- | Attaching new module | 5 | TODO | TODO |- | Securing new module clamp | 5 | TODO | TODO |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | 5 | TODO | TODO |- | Recover hydrophone | 5 | TODO | TODO |- | Pull ghost net pin | 10 | TODO | TODO |- | Remove ghost net from water | 5 | TODO | TODO |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | 15 | Only 5 points if done manually TODO | TODO |- | rowspan="5"|2.1 Inspecting fish pen | Autonomous transect/inspection | 25 | 10 points if done manually TODO | TODO |- | Identifying damaged net areas | 5 | TODO | TODO |- | Repairing damaged net area | 10 | TODO | TODO |- | Removing encrusting marine growth | 5 | TODO | TODO |- | Removing algal marine growth | 5 | TODO | TODO |- | rowspan="3"|2.2 Maintaining a healthy environment | AI identification of "morts" | 10 | TODO | TODO |- | Collecting a "mort" | 5 | TODO | TODO |- | Putting "mort" in collection tube | 5 | TODO | TODO |- | rowspan="2"|2.3 Measure fish size | Determine average fish size | 15 | Must be within 2 cm TODO | TODO |- | Determine biomass of fish | 5 | TODO | TODO |- | rowspan="2"|2.4 Farm seagrass | Prune existing seagrass | 5 | TODO | TODO |- | Plant new seagrass | 5 | TODO | TODO |- | rowspan="5"|3.1 MATE Floats! | Determine GO-BGC surfacing location | 5 | TODO | TODO |- | Recover GO-BGC float | 10 | TODO | TODO |- | Build float before competition | 5 | TODO | TODO |- | Deploy float in designated area | 5 | TODO | TODO |- | Float completes two profiles | 25 | 15 points if only one profile TODO | TODO |- | rowspan="5"|2.2 Endurance22 | Fly transect over wreck | 10 | TODO | TODO |- | Map wreck (by hand) | 5 | TODO | TODO |- | Collect images of all wreck sections | 5 | TODO | TODO |- | Autonomous photomosaic of wreck | 20 | Only 10 points if done manually | TODO |- | Measure length of wreck (error < 10 cm) | 10 | Only 5 points if 10 cm < error < 20 cm, 0 points otherwise. TODO | TODO |} 4a99ff31927a4588fb8e6dbdc41f9f58d134fb71 340 339 2022-02-23T22:12:40Z Alnis S 6 wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!class="unsortable"|Subtask!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!Points!!class="unsortable"|Scoring condition!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 23 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Cutting cable | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing damaged cable | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Installing new cable | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new cable | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recovering old module | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Attaching new module | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new module clamp | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover hydrophone | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Pull ghost net pin | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Remove ghost net from water | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | PAGE | 15 | Only 5 points if done manually | DESCRIPTION | CATEGORIES |- | rowspan="5"|2.1 Inspecting fish pen | Autonomous transect/inspection | PAGE | 25 | 10 points if done manually | DESCRIPTION | CATEGORIES |- | Identifying damaged net areas | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Repairing damaged net area | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing encrusting marine growth | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Removing algal marine growth | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="3"|2.2 Maintaining a healthy environment | AI identification of "morts" | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Collecting a "mort" | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Putting "mort" in collection tube | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.3 Measure fish size | Determine average fish size | PAGE | 15 | Must be within 2 cm TODO | DESCRIPTION | CATEGORIES |- | Determine biomass of fish | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.4 Farm seagrass | Prune existing seagrass | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Plant new seagrass | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.1 MATE Floats! | Determine GO-BGC surfacing location | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover GO-BGC float | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Build float before competition | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Deploy float in designated area | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Float completes two profiles | PAGE | 25 | 15 points if only one profile | DESCRIPTION | CATEGORIES |- | rowspan="5"|2.2 Endurance22 | Fly transect over wreck | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Map wreck (by hand) | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Collect images of all wreck sections | PAGE | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Autonomous photomosaic of wreck | PAGE | 20 | Only 10 points if done manually | DESCRIPTION | CATEGORIES |- | Measure length of wreck (error < 10 cm) | PAGE | 10 | Only 5 points if 10 cm < error < 20 cm, 0 points otherwise. TODO | DESCRIPTION | CATEGORIES |} d99332e085b75f36a649da846823e17a1c9cdd6b 341 340 2022-02-23T22:52:39Z Alnis S 6 wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!class="unsortable"|Subtask!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!Points!!class="unsortable"|Scoring condition!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Cutting cable | 22 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing damaged cable | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Installing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | 23 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recovering old module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Attaching new module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new module clamp | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Pull ghost net pin | 24 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Remove ghost net from water | 25 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | 25 | 15 | Only 5 points if done manually | DESCRIPTION | CATEGORIES |- | rowspan="5"|2.1 Inspecting fish pen | Autonomous transect/inspection | PAGE | 25 | 10 points if done manually | DESCRIPTION | CATEGORIES |- | Identifying damaged net areas | 27 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Repairing damaged net area | 28 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing encrusting marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Removing algal marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="3"|2.2 Maintaining a healthy environment | AI identification of "morts" | 29 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Collecting a "mort" | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Putting "mort" in collection tube | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.3 Measure fish size | Determine average fish size | 30 | 15 | Must be within 2 cm TODO | DESCRIPTION | CATEGORIES |- | Determine biomass of fish | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.4 Farm seagrass | Prune existing seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Plant new seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.1 MATE Floats! | Determine GO-BGC surfacing location | 32 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover GO-BGC float | 33 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Build float before competition | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Deploy float in designated area | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Float completes two profiles | 34 | 25 | 15 points if only one profile | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.2 Endurance22 | Fly transect over wreck | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Map wreck (by hand) | 35 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Collect images of all wreck sections | 36 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Autonomous photomosaic of wreck | 36 | 20 | Only 10 points if done manually | DESCRIPTION | CATEGORIES |- | Measure length of wreck (error < 10 cm) | 37 | 10 | Only 5 points if 10 cm < error < 20 cm, 0 points otherwise. TODO | DESCRIPTION | CATEGORIES |- | rowspan="5"|Penalties | Bumping into the wreck | 38 | -5 | 5 points deducted per contact, up to 25 total | Every time the ROV (including tether etc.) comes into contact with wreck, the penalty is deducted. | CATEGORIES |- | Going over time | 65 | -1 | 1 point deducted per minute | Penalty starts to be assessed after 5-minute demobilization period ends | CATEGORIES |- | Tether pulling | 65 | -5 | First time is a warning, then 5 points deducted per infraction | Pulling on tether to speed up recovery of items or vehicle is prohibited. Manipulating the tether to free it from obstacles does not count. | CATEGORIES |- | SCUBA assistance | 65 | -5 | 5 points deducted per diver assist | Divers will be available to assist at the World Championship. If help is needed, the CEO or pilot musk ask judge and divers for assistance. The demonstration clock does not stop during assistance. | CATEGORIES |- | Pilot-poolside communication | 66 | -5 | First time is a warning, then 5 points deducted per infraction | Only tether management issues (how much is out, how much remains on pool deck) may be discussed. No directional or demonstration task information can be communicated to the pilot. | CATEGORIES |- | Outside communication | 66 | Disqualification | Disqualification. No exceptions. | ROV and its control system is not allowed to broadcast video or other information outside of the product demonstration area. Teams may not use Zoom, Skype, Facebook, Twitter, messaging, etc. during the demonstration. | CATEGORIES |- | Challenging chief judge ruling | 66 | Penalty points | Discretionary | Challenging a chief judge ruling, including appeals to other competition officials, will result in penalty points. | CATEGORIES |- | Transferring wreck mosaic images | 37 | Disqualification | Disqualification. | Transferring wreck mosaic images outside of the product demonstration station is prohibited. However, after informing the station judge of their intent, companies may transfer images to a secondary device (e.g. laptop or tablet) at the demonstration station to stitch images on that device. |- | Use of non-inspected device | 46 | Disqualification | Disqualification. | Using a device that did not participate in and pass the safety inspection results in disqualification. | CATEGORIES |- | Disrespectful behavior | 62 | Discretionary | Penalty points or disqualification. | Disrespectful behavior toward judges, officials, pool staff, audience, or other companies will result in discretionary penalty points or disqualification. | CATEGORIES |- | Unsavory behavior | 62 | Disqualification | Disqualification. | Sabotage, stealing, pilfering, and cheating will result in disqualification. | CATEGORIES |- | Entering water | 66 | Discretionary | Penalty points or disqualification. |} f2ee83bb1edbae47cd7e9984eafdb2e69e018d37 342 341 2022-02-23T23:05:43Z Alnis S 6 wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!class="unsortable"|Subtask!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!Points!!class="unsortable"|Scoring condition!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Cutting cable | 22 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing damaged cable | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Installing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | 23 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recovering old module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Attaching new module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new module clamp | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Pull ghost net pin | 24 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Remove ghost net from water | 25 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | 25 | 15 | Only 5 points if done manually | DESCRIPTION | CATEGORIES |- | rowspan="5"|2.1 Inspecting fish pen | Autonomous transect/inspection | PAGE | 25 | 10 points if done manually | DESCRIPTION | CATEGORIES |- | Identifying damaged net areas | 27 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Repairing damaged net area | 28 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing encrusting marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Removing algal marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="3"|2.2 Maintaining a healthy environment | AI identification of "morts" | 29 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Collecting a "mort" | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Putting "mort" in collection tube | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.3 Measure fish size | Determine average fish size | 30 | 15 | Must be within 2 cm TODO | DESCRIPTION | CATEGORIES |- | Determine biomass of fish | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.4 Farm seagrass | Prune existing seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Plant new seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.1 MATE Floats! | Determine GO-BGC surfacing location | 32 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover GO-BGC float | 33 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Build float before competition | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Deploy float in designated area | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Float completes two profiles | 34 | 25 | 15 points if only one profile | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.2 Endurance22 | Fly transect over wreck | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Map wreck (by hand) | 35 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Collect images of all wreck sections | 36 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Autonomous photomosaic of wreck | 36 | 20 | Only 10 points if done manually | DESCRIPTION | CATEGORIES |- | Measure length of wreck (error < 10 cm) | 37 | 10 | Only 5 points if 10 cm < error < 20 cm, 0 points otherwise. TODO | DESCRIPTION | CATEGORIES |- | rowspan="5"|Penalties | Bumping into the wreck | 38 | -5 | 5 points deducted per contact, up to 25 total | Every time the ROV (including tether etc.) comes into contact with wreck, the penalty is deducted. | CATEGORIES |- | Going over time | 65 | -1 | 1 point deducted per minute | Penalty starts to be assessed after 5-minute demobilization period ends | CATEGORIES |- | Tether pulling | 65 | -5 | First time is a warning, then 5 points deducted per infraction | Pulling on tether to speed up recovery of items or vehicle is prohibited. Manipulating the tether to free it from obstacles does not count. | CATEGORIES |- | SCUBA assistance | 65 | -5 | 5 points deducted per diver assist | Divers will be available to assist at the World Championship. If help is needed, the CEO or pilot musk ask judge and divers for assistance. The demonstration clock does not stop during assistance. | CATEGORIES |- | Pilot-poolside communication | 66 | -5 | First time is a warning, then 5 points deducted per infraction | Only tether management issues (how much is out, how much remains on pool deck) may be discussed. No directional or demonstration task information can be communicated to the pilot. | CATEGORIES |- | Outside communication | 66 | Disqualification | Disqualification. No exceptions. | ROV and its control system is not allowed to broadcast video or other information outside of the product demonstration area. Teams may not use Zoom, Skype, Facebook, Twitter, messaging, etc. during the demonstration. | CATEGORIES |- | Challenging chief judge ruling | 66 | Penalty points | Discretionary | Challenging a chief judge ruling, including appeals to other competition officials, will result in penalty points. | CATEGORIES |- | Transferring wreck mosaic images | 37 | Disqualification | Disqualification. | Transferring wreck mosaic images outside of the product demonstration station is prohibited. However, after informing the station judge of their intent, companies may transfer images to a secondary device (e.g. laptop or tablet) at the demonstration station to stitch images on that device. |- | Use of non-inspected device | 46 | Disqualification | Disqualification. | Using a device that did not participate in and pass the safety inspection results in disqualification. | CATEGORIES |- | Disrespectful behavior | 62 | Discretionary | Penalty points or disqualification. | Disrespectful behavior toward judges, officials, pool staff, audience, or other companies will result in discretionary penalty points or disqualification. | CATEGORIES |- | Unsavory behavior | 62 | Disqualification | Disqualification. | Sabotage, stealing, pilfering, and cheating will result in disqualification. | CATEGORIES |- | Entering water | 66 | Discretionary | Penalty points or disqualification. | Only arms and hands are allowed into the pool to retrieve an object or the vehicle. No members shall enter the water for recovery. Penalty will depend on severity of infraction. |} cea4d59bb2ab8072c6c125ae0943cdabc723a6a8 343 342 2022-02-23T23:54:46Z Alnis S 6 wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!class="unsortable"|Subtask!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!Points!!class="unsortable"|Scoring condition!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Cutting cable | 22 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing damaged cable | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Installing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | 23 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recovering old module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Attaching new module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new module clamp | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Pull ghost net pin | 24 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Remove ghost net from water | 25 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | 25 | 15 | Only 5 points if done manually | DESCRIPTION | CATEGORIES |- | rowspan="5"|2.1 Inspecting fish pen | Autonomous transect/inspection | PAGE | 25 | 10 points if done manually | DESCRIPTION | CATEGORIES |- | Identifying damaged net areas | 27 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Repairing damaged net area | 28 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing encrusting marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Removing algal marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="3"|2.2 Maintaining a healthy environment | AI identification of "morts" | 29 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Collecting a "mort" | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Putting "mort" in collection tube | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.3 Measure fish size | Determine average fish size | 30 | 15 | Must be within 2 cm TODO | DESCRIPTION | CATEGORIES |- | Determine biomass of fish | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.4 Farm seagrass | Prune existing seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Plant new seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.1 MATE Floats! | Determine GO-BGC surfacing location | 32 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover GO-BGC float | 33 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Build float before competition | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Deploy float in designated area | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Float completes two profiles | 34 | 25 | 15 points if only one profile | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.2 Endurance22 | Fly transect over wreck | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Map wreck (by hand) | 35 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Collect images of all wreck sections | 36 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Autonomous photomosaic of wreck | 36 | 20 | Only 10 points if done manually | DESCRIPTION | CATEGORIES |- | Measure length of wreck (error < 10 cm) | 37 | 10 | Only 5 points if 10 cm < error < 20 cm, 0 points otherwise. TODO | DESCRIPTION | CATEGORIES |} == Table of Penalties == {|class="wikitable sortable" !Task!!class="unsortable"|Subtask!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!Points!!class="unsortable"|Scoring condition!!class="unsortable"|Description!!Categories |- | rowspan="5"|Penalties | Bumping into the wreck | 38 | -5 | 5 points deducted per contact, up to 25 total | Every time the ROV (including tether etc.) comes into contact with wreck, the penalty is deducted. | CATEGORIES |- | Going over time | 65 | -1 | 1 point deducted per minute | Penalty starts to be assessed after 5-minute demobilization period ends | CATEGORIES |- | Tether pulling | 65 | -5 | First time is a warning, then 5 points deducted per infraction | Pulling on tether to speed up recovery of items or vehicle is prohibited. Manipulating the tether to free it from obstacles does not count. | CATEGORIES |- | SCUBA assistance | 65 | -5 | 5 points deducted per diver assist | Divers will be available to assist at the World Championship. If help is needed, the CEO or pilot musk ask judge and divers for assistance. The demonstration clock does not stop during assistance. | CATEGORIES |- | Pilot-poolside communication | 66 | -5 | First time is a warning, then 5 points deducted per infraction | Only tether management issues (how much is out, how much remains on pool deck) may be discussed. No directional or demonstration task information can be communicated to the pilot. | CATEGORIES |} == Table of Disqualifications {|class="wikitable sortable" !Rule!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!class="unsortable"|Penalty!!class="unsortable"|Description!!Categories |- | Outside communication | 66 | Disqualification (no exceptions) | ROV and its control system is not allowed to broadcast video or other information outside of the product demonstration area. Teams may not use Zoom, Skype, Facebook, Twitter, messaging, etc. during the demonstration. | CATEGORIES |- | Challenging chief judge ruling | 66 | Discretionary penalty points | Challenging a chief judge ruling, including appeals to other competition officials, will result in penalty points. | CATEGORIES |- | Transferring wreck mosaic images | 37 | Disqualification. | Transferring wreck mosaic images outside of the product demonstration station is prohibited. However, after informing the station judge of their intent, companies may transfer images to a secondary device (e.g. laptop or tablet) at the demonstration station to stitch images on that device. | CATEGORIES |- | Use of non-inspected device | 46 | Disqualification | Using a device that did not participate in and pass the safety inspection results in disqualification. | CATEGORIES |- | Disrespectful behavior | 62 | Discretionary penalty points or disqualification | Disrespectful behavior toward judges, officials, pool staff, audience, or other companies will result in discretionary penalty points or disqualification. | CATEGORIES |- | Unsavory behavior | 62 | Disqualification | Sabotage, stealing, pilfering, and cheating will result in disqualification. | CATEGORIES |- | Entering water | 66 | Discretionary penalty points or disqualification | Only arms and hands are allowed into the pool to retrieve an object or the vehicle. No members shall enter the water for recovery. Penalty will depend on severity of infraction. | CATEGORIES |} 440ad2a300dec2fb14a54b9946967e252cf5a201 344 343 2022-02-24T00:00:16Z Alnis S 6 /* Table of Penalties */ wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!class="unsortable"|Subtask!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!Points!!class="unsortable"|Scoring condition!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Cutting cable | 22 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing damaged cable | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Installing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | 23 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recovering old module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Attaching new module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new module clamp | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Pull ghost net pin | 24 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Remove ghost net from water | 25 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | 25 | 15 | Only 5 points if done manually | DESCRIPTION | CATEGORIES |- | rowspan="5"|2.1 Inspecting fish pen | Autonomous transect/inspection | PAGE | 25 | 10 points if done manually | DESCRIPTION | CATEGORIES |- | Identifying damaged net areas | 27 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Repairing damaged net area | 28 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing encrusting marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Removing algal marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="3"|2.2 Maintaining a healthy environment | AI identification of "morts" | 29 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Collecting a "mort" | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Putting "mort" in collection tube | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.3 Measure fish size | Determine average fish size | 30 | 15 | Must be within 2 cm TODO | DESCRIPTION | CATEGORIES |- | Determine biomass of fish | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.4 Farm seagrass | Prune existing seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Plant new seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.1 MATE Floats! | Determine GO-BGC surfacing location | 32 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover GO-BGC float | 33 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Build float before competition | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Deploy float in designated area | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Float completes two profiles | 34 | 25 | 15 points if only one profile | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.2 Endurance22 | Fly transect over wreck | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Map wreck (by hand) | 35 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Collect images of all wreck sections | 36 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Autonomous photomosaic of wreck | 36 | 20 | Only 10 points if done manually | DESCRIPTION | CATEGORIES |- | Measure length of wreck (error < 10 cm) | 37 | 10 | Only 5 points if 10 cm < error < 20 cm, 0 points otherwise. TODO | DESCRIPTION | CATEGORIES |} == Table of Penalties == {|class="wikitable sortable" !Task!!class="unsortable"|Subtask!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!Points!!class="unsortable"|Scoring condition!!class="unsortable"|Description!!Categories |- | rowspan="5"|Penalties | Bumping into the wreck | 38 | -5 | 5 points deducted per contact, up to 25 total | Every time the ROV (including tether etc.) comes into contact with wreck, the penalty is deducted. | CATEGORIES |- | Going over time | 65 | -1 | 1 point deducted per minute | Penalty starts to be assessed after 5-minute demobilization period ends | CATEGORIES |- | Tether pulling | 65 | -5 | First time is a warning, then 5 points deducted per infraction | Pulling on tether to speed up recovery of items or vehicle is prohibited. Manipulating the tether to free it from obstacles does not count. | CATEGORIES |- | SCUBA assistance | 65 | -5 | 5 points deducted per diver assist | Divers will be available to assist at the World Championship. If help is needed, the CEO or pilot musk ask judge and divers for assistance. The demonstration clock does not stop during assistance. | CATEGORIES |- | Pilot-poolside communication | 66 | -5 | First time is a warning, then 5 points deducted per infraction | Only tether management issues (how much is out, how much remains on pool deck) may be discussed. No directional or demonstration task information can be communicated to the pilot. | CATEGORIES |} == Table of Disqualifications == {|class="wikitable sortable" !Rule!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!class="unsortable"|Penalty!!class="unsortable"|Description!!Categories |- | Outside communication | 66 | Disqualification (no exceptions) | ROV and its control system is not allowed to broadcast video or other information outside of the product demonstration area. Teams may not use Zoom, Skype, Facebook, Twitter, messaging, etc. during the demonstration. | CATEGORIES |- | Challenging chief judge ruling | 66 | Discretionary penalty points | Challenging a chief judge ruling, including appeals to other competition officials, will result in penalty points. | CATEGORIES |- | Transferring wreck mosaic images | 37 | Disqualification. | Transferring wreck mosaic images outside of the product demonstration station is prohibited. However, after informing the station judge of their intent, companies may transfer images to a secondary device (e.g. laptop or tablet) at the demonstration station to stitch images on that device. | CATEGORIES |- | Use of non-inspected device | 46 | Disqualification | Using a device that did not participate in and pass the safety inspection results in disqualification. | CATEGORIES |- | Disrespectful behavior | 62 | Discretionary penalty points or disqualification | Disrespectful behavior toward judges, officials, pool staff, audience, or other companies will result in discretionary penalty points or disqualification. | CATEGORIES |- | Unsavory behavior | 62 | Disqualification | Sabotage, stealing, pilfering, and cheating will result in disqualification. | CATEGORIES |- | Entering water | 66 | Discretionary penalty points or disqualification | Only arms and hands are allowed into the pool to retrieve an object or the vehicle. No members shall enter the water for recovery. Penalty will depend on severity of infraction. | CATEGORIES |} c2435a697b0f49bbbea8f559cce742e943ad8a78 345 344 2022-02-24T00:02:09Z Alnis S 6 Alnis S moved page [[2022 MATE EXPLORER Tasks]] to [[2022 MATE EXPLORER Summary]]: Scope has been expanded to penalties and disqualifications (beyond original task focus) wikitext text/x-wiki == Table of Tasks == {|class="wikitable sortable" !Task!!class="unsortable"|Subtask!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!Points!!class="unsortable"|Scoring condition!!class="unsortable"|Description!!Categories |- | rowspan="5"|1.1 Replacing power cable | Visual inspection | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Cutting cable | 22 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing damaged cable | 22 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Installing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new cable | 23 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.2 Replacing buoyancy module | Releasing old module clamp | 23 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recovering old module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Attaching new module | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Securing new module clamp | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="4"|1.3 Monitor the environment | Deploy hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover hydrophone | 24 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Pull ghost net pin | 24 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Remove ghost net from water | 25 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="1"|1.4 Return to docking station | Autonomous docking | 25 | 15 | Only 5 points if done manually | DESCRIPTION | CATEGORIES |- | rowspan="5"|2.1 Inspecting fish pen | Autonomous transect/inspection | PAGE | 25 | 10 points if done manually | DESCRIPTION | CATEGORIES |- | Identifying damaged net areas | 27 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Repairing damaged net area | 28 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Removing encrusting marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Removing algal marine growth | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="3"|2.2 Maintaining a healthy environment | AI identification of "morts" | 29 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Collecting a "mort" | 29 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Putting "mort" in collection tube | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.3 Measure fish size | Determine average fish size | 30 | 15 | Must be within 2 cm TODO | DESCRIPTION | CATEGORIES |- | Determine biomass of fish | 30 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="2"|2.4 Farm seagrass | Prune existing seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Plant new seagrass | 31 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.1 MATE Floats! | Determine GO-BGC surfacing location | 32 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Recover GO-BGC float | 33 | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Build float before competition | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Deploy float in designated area | 34 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Float completes two profiles | 34 | 25 | 15 points if only one profile | DESCRIPTION | CATEGORIES |- | rowspan="5"|3.2 Endurance22 | Fly transect over wreck | PAGE | 10 | SCORING | DESCRIPTION | CATEGORIES |- | Map wreck (by hand) | 35 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Collect images of all wreck sections | 36 | 5 | SCORING | DESCRIPTION | CATEGORIES |- | Autonomous photomosaic of wreck | 36 | 20 | Only 10 points if done manually | DESCRIPTION | CATEGORIES |- | Measure length of wreck (error < 10 cm) | 37 | 10 | Only 5 points if 10 cm < error < 20 cm, 0 points otherwise. TODO | DESCRIPTION | CATEGORIES |} == Table of Penalties == {|class="wikitable sortable" !Task!!class="unsortable"|Subtask!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!Points!!class="unsortable"|Scoring condition!!class="unsortable"|Description!!Categories |- | rowspan="5"|Penalties | Bumping into the wreck | 38 | -5 | 5 points deducted per contact, up to 25 total | Every time the ROV (including tether etc.) comes into contact with wreck, the penalty is deducted. | CATEGORIES |- | Going over time | 65 | -1 | 1 point deducted per minute | Penalty starts to be assessed after 5-minute demobilization period ends | CATEGORIES |- | Tether pulling | 65 | -5 | First time is a warning, then 5 points deducted per infraction | Pulling on tether to speed up recovery of items or vehicle is prohibited. Manipulating the tether to free it from obstacles does not count. | CATEGORIES |- | SCUBA assistance | 65 | -5 | 5 points deducted per diver assist | Divers will be available to assist at the World Championship. If help is needed, the CEO or pilot musk ask judge and divers for assistance. The demonstration clock does not stop during assistance. | CATEGORIES |- | Pilot-poolside communication | 66 | -5 | First time is a warning, then 5 points deducted per infraction | Only tether management issues (how much is out, how much remains on pool deck) may be discussed. No directional or demonstration task information can be communicated to the pilot. | CATEGORIES |} == Table of Disqualifications == {|class="wikitable sortable" !Rule!!class="unsortable"|[https://files.materovcompetition.org/2022/2022_EXPLORER_Manual_21_JAN_2022.pdf Page]!!class="unsortable"|Penalty!!class="unsortable"|Description!!Categories |- | Outside communication | 66 | Disqualification (no exceptions) | ROV and its control system is not allowed to broadcast video or other information outside of the product demonstration area. Teams may not use Zoom, Skype, Facebook, Twitter, messaging, etc. during the demonstration. | CATEGORIES |- | Challenging chief judge ruling | 66 | Discretionary penalty points | Challenging a chief judge ruling, including appeals to other competition officials, will result in penalty points. | CATEGORIES |- | Transferring wreck mosaic images | 37 | Disqualification. | Transferring wreck mosaic images outside of the product demonstration station is prohibited. However, after informing the station judge of their intent, companies may transfer images to a secondary device (e.g. laptop or tablet) at the demonstration station to stitch images on that device. | CATEGORIES |- | Use of non-inspected device | 46 | Disqualification | Using a device that did not participate in and pass the safety inspection results in disqualification. | CATEGORIES |- | Disrespectful behavior | 62 | Discretionary penalty points or disqualification | Disrespectful behavior toward judges, officials, pool staff, audience, or other companies will result in discretionary penalty points or disqualification. | CATEGORIES |- | Unsavory behavior | 62 | Disqualification | Sabotage, stealing, pilfering, and cheating will result in disqualification. | CATEGORIES |- | Entering water | 66 | Discretionary penalty points or disqualification | Only arms and hands are allowed into the pool to retrieve an object or the vehicle. No members shall enter the water for recovery. Penalty will depend on severity of infraction. | CATEGORIES |} c2435a697b0f49bbbea8f559cce742e943ad8a78 0 51 346 2022-02-24T00:02:09Z Alnis S 6 Alnis S moved page [[2022 MATE EXPLORER Tasks]] to [[2022 MATE EXPLORER Summary]]: Scope has been expanded to penalties and disqualifications (beyond original task focus) wikitext text/x-wiki #REDIRECT [[2022 MATE EXPLORER Summary]] db23bf74c7b074248cae72deafb4758d4ab7d3cd 0 42 351 350 2022-04-10T07:38:14Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |[[Design for 3D Printing]]: CAD Tips||Tips and tricks for effectively using CAD for 3D printed parts||Weekend of Jan 29 & 30 |- |[[Design for Sheet Metal]]: Introduction||A quick introduction to designing parts that can be made from cut and folded sheet metal||Weekend of Feb 5 & 6 |- |[http://507movements.com/ 507 Mechanical Movements]||Hundreds of interesting mechanisms and contraptions. Post one that seems relevant to ROV in #me-learning!||2022-02-20 |- |[https://vimeo.com/679543161 MATE flythrough video]||Animated overview of this year's competition||2022-02-27 |- |[https://youtu.be/l2nNmENmMdk How To Make Prototypes: Jeremy Fielding]||A video on the process of prototyping robotic systems. What is one takeaway/quotable quote that you found useful or inspiring?||2022-03-06 |- |[https://youtu.be/fmXFWi-WfyU Rotational motion]<br>[https://youtu.be/b-HZ1SZPaQw Torque]<br>[https://youtu.be/9cbF9A6eQNA Statics crash course]||Three short (~10 min) videos that provide a great intuitive grounding in mechanical analysis.<br>No need to take notes or remember formulas---just try to absorb the general concepts and keywords.||2022-03-28 |- |[https://youtu.be/UYv1pQnQvP4?t=167 Motors and Speed Controllers (can skip to 2:47)]<br>[https://youtu.be/enFKeOcjreE Electronics]||Two 15-minute videos from Battlebots Team Witch Doctor about combat robotics electronics. We're not building a combat robot and the videos are in large part about putting together a kit, but the parts about ESCs and motors are relevant! Note: these videos discuss brushed DC motors, while we use brushless motors. The wiring overall is similar, but not quite the same. Next week will have info about brushless motors!||2022-04-10 |- |} d61a7bde21445c787239d3283c1de59c7b35efa8 352 351 2022-04-10T07:40:43Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |[[Design for 3D Printing]]: CAD Tips||Tips and tricks for effectively using CAD for 3D printed parts||Weekend of Jan 29 & 30 |- |[[Design for Sheet Metal]]: Introduction||A quick introduction to designing parts that can be made from cut and folded sheet metal||Weekend of Feb 5 & 6 |- |[http://507movements.com/ 507 Mechanical Movements]||Hundreds of interesting mechanisms and contraptions. Post one that seems relevant to ROV in #me-learning!||2022-02-20 |- |[https://vimeo.com/679543161 MATE flythrough video]||Animated overview of this year's competition||2022-02-27 |- |[https://youtu.be/l2nNmENmMdk How To Make Prototypes: Jeremy Fielding]||A video on the process of prototyping robotic systems. What is one takeaway/quotable quote that you found useful or inspiring?||2022-03-06 |- |[https://youtu.be/fmXFWi-WfyU Rotational motion]<br>[https://youtu.be/b-HZ1SZPaQw Torque]<br>[https://youtu.be/9cbF9A6eQNA Statics crash course]||Three short (~10 min) videos that provide a great intuitive grounding in mechanical analysis.<br>No need to take notes or remember formulas---just try to absorb the general concepts and keywords.||2022-03-28 |- |[https://youtu.be/UYv1pQnQvP4?t=167 Motors and Speed Controllers (2:47 to 4:19 is most relevant)]<br>[https://youtu.be/enFKeOcjreE Electronics]||Two 15-minute videos from Battlebots Team Witch Doctor about combat robotics electronics. We're not building a combat robot and the videos are in large part about putting together a kit, but the parts about ESCs and motors are relevant! Note: these videos discuss brushed DC motors, while we use brushless motors. The wiring overall is similar, but not quite the same. Next week will have info about brushless motors!||2022-04-10 |- |} 362349f3c87d60be995dfdfc7a85cc4ca31cfe16 353 352 2022-04-10T11:50:33Z Alnis S 6 wikitext text/x-wiki {|class="wikitable sortable" !Article!!class="unsortable"|Description!!data-sort-type="isoDate"|Date added |- |[[Design for 3D Printing]]: FDM Printer Tips||Tips and tricks for designing parts that will be printed using FDM printers||2022-01-17 |- |[https://youtu.be/AmEaNAwFSfI CNC Kitchen - 3D print strength vs infill & shell settings]<br>[https://forms.gle/N1J1o3RaJY2GUWF26 Quiz]|| Video about slicer settings and their effect on print strength, as well as a quick quiz||2022-01-23 |- |[[Design for 3D Printing]]: CAD Tips||Tips and tricks for effectively using CAD for 3D printed parts||Weekend of Jan 29 & 30 |- |[[Design for Sheet Metal]]: Introduction||A quick introduction to designing parts that can be made from cut and folded sheet metal||Weekend of Feb 5 & 6 |- |[http://507movements.com/ 507 Mechanical Movements]||Hundreds of interesting mechanisms and contraptions. Post one that seems relevant to ROV in #me-learning!||2022-02-20 |- |[https://vimeo.com/679543161 MATE flythrough video]||Animated overview of this year's competition||2022-02-27 |- |[https://youtu.be/l2nNmENmMdk How To Make Prototypes: Jeremy Fielding]||A video on the process of prototyping robotic systems. What is one takeaway/quotable quote that you found useful or inspiring?||2022-03-06 |- |[https://youtu.be/fmXFWi-WfyU Rotational motion]<br>[https://youtu.be/b-HZ1SZPaQw Torque]<br>[https://youtu.be/9cbF9A6eQNA Statics crash course]||Three short (~10 min) videos that provide a great intuitive grounding in mechanical analysis.<br>No need to take notes or remember formulas---just try to absorb the general concepts and keywords.||2022-03-28 |- |[https://youtu.be/UYv1pQnQvP4?t=167 Motors and Speed Controllers (2:47 to 4:19 is most relevant)]<br>[https://youtu.be/enFKeOcjreE Electronics]<br>[https://youtu.be/1WnGv-DPexc?t=54 What are servos and how do they work?]||Two 15-minute videos from Battlebots Team Witch Doctor about combat robotics electronics. We're not building a combat robot and the videos are in large part about putting together a kit, but the parts about ESCs and motors are relevant! Note: these videos discuss brushed DC motors, while we use brushless motors. The wiring overall is similar, but not quite the same. Next week will have info about brushless motors!<br>Also: there's a third, 15-minute video on servos. It's not perfect & has some errors but it's a good intro video!||2022-04-10 |- |} f9e06f84914f7b6341203b8e684d681cfc5f8493 0 29 354 298 2022-06-05T00:56:48Z Alnis S 6 wikitext text/x-wiki This article contains an overview of our 2022 MATE ROV. This mostly relates to our initial design work & concept development. For a complete overview of all of our ROV's systems, please check out this year's technical documentation: https://docs.google.com/document/d/1Jx9gZEaPf9MhOh9jwkcxz7RpG8zUiVvOCw2-BichGos/edit#heading=h.ijw7dyoklmfc == Requirements == * Structure brainstorming document from December 1st mechanical meeting: https://docs.google.com/document/d/1O9PdNfr3XDEzvGZIYUeGRbBSmk7omGKim_zjr-hEQpk/edit * Propulsion brainstorming document from asynchronous work: https://docs.google.com/document/d/14a_t_G7UHeeSwe83yFSbcJ1G9XAckY_LQPh8CJ6UZoc/edit {|class="wikitable" !Subsystem!!Must-have!!Nice to have |-style="vertical-align: top;" | Overall ROV || Organizational requirements: * Within budget Design requirements: * Can deploy through a 1-meter square * Less than 35 kg * Balanced & manually re-balanceable * Can survive shipping and regular operation * Risk of entanglement is mitigated || Design goals * Modular and adjustable * Simple: avoids overcomplication * Robust materials (no zip ties!) * No interference/conflicts between subsystems * Less than 20 kg (for bonus points) Easy to... * Develop and design * Carry and move * Manufacture |-style="vertical-align: top;" | Structure || General requirements: * Neutrally buoyant * Can stand on its own * Protection for delicate systems Mounting/housing for other subsystems: * Thruster mounting * Manipulator mounting * Conflict-free camera mounting: forward, down, and manipulator * Housing the electronics || * Mounting for external sensors * Nice to have camera views: rear, left, right * Lighting to improve colors at larger depths * Lasers for rangefinding * Single pressure hold makes it easier for electronics |-style="vertical-align: top;" | Propulsion || General requirements: * ROV is sufficiently maneuverable to complete competition tasks || * Easily detachable for easier transportation * Easy and intuitive to maneuver for human pilot * Does not require advanced software + electronics to be fully usable * Software team prefers 6 degrees of freedom |-style="vertical-align: top;" | Manipulator || * || * Ideally two manipulators to simultaneously do two tasks |} == Design Concepts == Template: [[Design Concept Template]] === Structure === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Aisha | | | * | * |-style="vertical-align: top;" | Alnis | [[Structure Concept: Big Ol' Plate]] | Put everything on a big plate that has lots of holes in a grid | * Easy to mount stuff * Structurally simple | * Inefficient with mass * Not very sleek |-style="vertical-align: top;" | Anna | | | * | * |-style="vertical-align: top;" | Cassandra | | | * | * |-style="vertical-align: top;" | Kenneth | * [[Structure Concept 1: Basically Hercules]] * In progress concept: [[Structure Concept 2: Ariana-I Inspired]] | A design similar to the ROV Hercules from the Nautilus exploration program. | * Tried and validated frame * Gives more freedom and visibility to the manipulator. | * May require two pressure hold or places for electronics. * Or will require a redesign of the current pressure hold due to relocation of the tether. |-style="vertical-align: top;" | Teddy | [[Structure Concept: Modular Rails]] | Use modular aluminum x rails or similar parts to create a frame that's easy to work with. | * Very easy to add and remove parts/prototypes * Dimensions can be changed easily if design plans change * Easy to manufacture, doesn't require machining | * Not quite as rigid * Parts need to be securely fastened to prevent sliding * Can be somewhat limited by the shape of x rails, although you can make custom lengths or plates |} === Propulsion === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | Amanda | | | * | * |-style="vertical-align: top;" | Ronan | | | * | * |} === Manipulator === {|class="wikitable" !Author!!Concept!!Summary!!Advantages!!Disadvantages |-style="vertical-align: top;" | | | | | |} == 1.0 Iteration == January 2022 === Key Design Decisions === Made at [[Mechanical Meeting Notes#January 2nd, 2022 - Winter Quarter Kickoff|January 2nd, 2022 (Winter Quarter Kickoff)]] meeting. Approximate pressure hold size (similar, larger, smaller vs last year?) * Kenneth: smaller than last year main hull, one or two satellite ones for cameras * Anna: smaller separate ones for cameras * Ronan: same size, plus extra smaller ones for cameras * Teddy: same main size, adding waterproof cameras/little camera pressure holds * Cassandra: same main size, adding waterproof satellite cameras * Consensus: use the same size as last year, but develop secondary waterproof housings for cameras Propulsion: 6 DOF or not? * Maybe don’t need rolling rotation * Probably need to know competition/manipulation details * Better to have it than to not have it, but not if it adds difficulty * Maybe just moving manipulator is easier * Wait until later to see if it’s necessary * '''Consensus''': Wait and see, but don’t cut off design directions. Nice to have, but not a problem if we don't have it. Clear pressure hold or not? * Opaque with satellite cameras => More flexibility for cameras, less challenges with distortion of camera views * Maybe mineral oil for coolant/sealing? Is resin thermally conductive? * Would provide a thermal advantage to use metal and space advantage to not have cameras inside * '''Consensus''': continue with large clear pressure hold, maybe go small and opaque pending how underwater cameras go Two manipulators or not? * Start with one as the main goal, but don’t go down a design path that prevents building a second one * Aim to have two manipulators in the second iteration * '''Consensus''': first iteration will target one manipulator, but likely target two for the second iteration Any other nice-to-haves we want to include? * None at the moment === ROV Core === Group design guidance: * Good set-down-ability: a handle and rubber feet * 6 DOF propulsion without funny motor angles like [[Structure Concept 2: Ariana-I Inspired|Ariana-I design concept]] * Avoid large solid/flat parts for easier movement through water * Ensure room on the bottom for a camera and/or manipulator * Ensure easy redistribution/balancing of weight * Be mindful of tether connection ** Prevent thruster interference ** Ensure connection doesn't make ROV hard to balance * Use a build system (C channel, X rail, etc.) ** Improves ease of adjustability and iteration ** If using X rail, ensure some way to keep positions accurate. ** Easy to modify design and take apart for shipping * Top-down external camera view to see manipulator ** Requires a waterproof camera/secondary enclosure ** Improves pilot awareness and ease of manipulator positioning Recommended timeline: * Week of Jan 3: planning, research, preliminary design * Week of Jan 10: detailed prototype design work (CAD) * Week of Jan 17: fabrication, procurement, and assembly * Week of Jan 24: testing and refinement * Week of Jan 31: integration! === Manipulator === Recommended timeline: * Week of Jan 3: planning, research, preliminary design to test * Week of Jan 10: hack together a prototype and test it * Week of Jan 17: detailed prototype design work (CAD) * Week of Jan 24: fabrication, procurement, and assembly, hopefully testing and refinement * Week of Jan 31: integration! === Float === Recommended timeline: * Week of Jan 3: planning, research, preliminary design * Week of Jan 10: detailed prototype design work (CAD) * Week of Jan 17: detailed prototype design work (CAD) * Week of Jan 24: fabrication, procurement, and assembly * Week of Jan 31: fabrication, procurement, and assembly, plus maybe testing! === Miscellaneous === Recommended timeline: * Week of Jan 3: planning, research, block diagram of surface station + basic planning, proof of concept simulation import * Week of Jan 10: refine simulation import process to work with more complex model, more detailed surface station design work * Week of Jan 17: work with ROV Core to import existing frame/propulsion to simulation, review and refine surface station with software & electrical * Week of Jan 24: test code with simulated ROV, fabrication, procurement, and assembly of surface station * Week of Jan 31: test code with simulated ROV, fabrication, procurement, and assembly of surface station aebfb6a7ac4aaa911766b67ee24bec73a86d7282 0 21 355 299 2022-06-05T23:30:04Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. For our 2022 ROV design overview, please see [[ROV22 Design Overview]]. For 2022 technical documentation, see this Google Doc: https://docs.google.com/document/d/1Jx9gZEaPf9MhOh9jwkcxz7RpG8zUiVvOCw2-BichGos/edit For a list of mechanical learning resources, please see [[Mechanical Learning Resources]]. Useful templates: * [[Design Concept Template]] <em>“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry, Airman's Odyssey</em> [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). === What are our goals for Autumn 2021? === We have two primary overarching goals: * Everyone has a baseline ability to use CAD * Everyone has designed and made something with the 3D printer and the waterjet On a more technical/deliverable level, we will make: * Underwater camera system prototype * Pressure hold that can go in the water * Prototype for each mechanism on ROV (can be manually powered) == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) 0298c787c1004aba4ff3d2cb784459766772b4ff 356 355 2022-06-19T09:40:19Z Alnis S 6 wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. For our 2022 ROV design overview, please see [[ROV22 Design Overview]]. For 2022 technical documentation, see this Google Doc: https://docs.google.com/document/d/1Jx9gZEaPf9MhOh9jwkcxz7RpG8zUiVvOCw2-BichGos/edit For a list of mechanical learning resources, please see [[Mechanical Learning Resources]]. Useful templates: * [[Design Concept Template]] <em>“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry, Airman's Odyssey</em> [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). === What are our goals for Autumn 2021? === We have two primary overarching goals: * Everyone has a baseline ability to use CAD * Everyone has designed and made something with the 3D printer and the waterjet On a more technical/deliverable level, we will make: * Underwater camera system prototype * Pressure hold that can go in the water * Prototype for each mechanism on ROV (can be manually powered) == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) * [https://cad.onshape.com/documents/a43bc6ffbce7e900b8ba667d/w/86c500787f23eca298c5ac57/e/c5be007f13a2057bea015cad] (test link) d22be812515059061d86921d73fee039d0914293 357 356 2022-06-19T09:42:13Z Alnis S 6 /* Resources */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. For our 2022 ROV design overview, please see [[ROV22 Design Overview]]. For 2022 technical documentation, see this Google Doc: https://docs.google.com/document/d/1Jx9gZEaPf9MhOh9jwkcxz7RpG8zUiVvOCw2-BichGos/edit For a list of mechanical learning resources, please see [[Mechanical Learning Resources]]. Useful templates: * [[Design Concept Template]] <em>“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry, Airman's Odyssey</em> [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). === What are our goals for Autumn 2021? === We have two primary overarching goals: * Everyone has a baseline ability to use CAD * Everyone has designed and made something with the 3D printer and the waterjet On a more technical/deliverable level, we will make: * Underwater camera system prototype * Pressure hold that can go in the water * Prototype for each mechanism on ROV (can be manually powered) == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) * [https://cad.onshape.com/documents/a43bc6ffbce7e900b8ba667d/w/86c500787f23eca298c5ac57/e/c5be007f13a2057bea015cad test link] (test link) 8f4c5e74898e4b8ca237a6c7db68835d2b38aaea 358 357 2022-06-19T09:42:37Z Alnis S 6 /* Resources */ wikitext text/x-wiki Welcome to the Mechanical subgroup page! It's currently under construction, but more information will be available here soon. For weekly meeting notes, please see [[Mechanical Meeting Notes]]. For our 2022 ROV design overview, please see [[ROV22 Design Overview]]. For 2022 technical documentation, see this Google Doc: https://docs.google.com/document/d/1Jx9gZEaPf9MhOh9jwkcxz7RpG8zUiVvOCw2-BichGos/edit For a list of mechanical learning resources, please see [[Mechanical Learning Resources]]. Useful templates: * [[Design Concept Template]] <em>“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry, Airman's Odyssey</em> [[File:ROV21 render 2021-08-01.png|thumb|right|ROV21 (Nautilus) Render as of August 1st, 2021]] == Summary == === What does UWROV's mechanical subgroup do? === We design, build, and maintain the physical ROV (everything except for electronics). Making detailed plans using CAD software is a key part of this process. Most importantly, continuously iterating and prototyping ensures we're always building systems that are fully functional. === I have a question. Who do I ask? === Post on Discord, ask Alnis, or ask someone else! Everyone here is friendly. === What does our work look like? === [https://cad.onshape.com/documents/b643bde957afced615cce3a5/w/f2b77404874607ee45551c96/e/9e6600d298eebd7ba3eda5df Our CAD model for our 2021 ROV] [http://uwrov.org/Nautilus Slightly out of date webpage about it] [https://photos.app.goo.gl/YQjDTLya5aE9xWR97 Photo album from summer 2021 worlds] There are three core areas of work for us: * Design - creating plans for everything physical on the ROV using CAD software (not including electronics) * Fabrication - implementing those plans by making parts and assembling the ROV * Documentation & Operations - communicating the design to others and supporting software & electrical members when they work with hardware When working on a project, there is a good chance you will jump between areas frequently. You are not bound to any roles--this is just a summary of what's out there to work on. === What tools do we use? === CAD: [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 Onshape] Project management: [https://uwrov.monday.com/ monday.com] Documentation: [https://uwrov.miraheze.org/wiki/Main_Page Mediawiki] Miscellaneous: [https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA Google Drive] === Why are we building an ROV? === We compete in the [https://materovcompetition.org/explorerspecs MATE explorer competition]. It’s like [https://www.firstinspires.org/ FIRST] for university students with a water game every year! === What are some key terms to know? === ROV - [https://en.wikipedia.org/wiki/Remotely_operated_underwater_vehicle Remotely Operated Vehicle]. Usually referencing an underwater robot. UWROV - [http://uwrov.org/ Under Water Remotely Operated Vehicle]. Blue - probably referencing [https://bluerobotics.com/ Blue Robotics], a key supplier of parts for ROVs. CAD - [https://en.wikipedia.org/wiki/Computer-aided_design Computer-Aided Design] (3D model of the ROV used for design, planning, etc.). MATE - [https://mateii.org/about-mate-ii/ Marine Advanced Technology Education] (the organization that runs the competition) === Where do we work? === Oceanography Building (OCE). Search OCE in your map software to get the right building! * Discord #mechanical channel: asynchronous work and hybrid meetings - '''FRIDAY MEETINGS 5-6 PM''' * OCE 118: Main Lab (workshop) - Mechanical and electrical workshop - '''WEDNESDAY MEETINGS 6-7 PM''' (lab open 5-8; please come for at least 2 hours) * OCE 119: Snack Room (meeting room) - Meetings, snacks, and programmers * OCE 121: Salish Sea Model Room (table room) - Lots of space to work * OCN pool: Ocean Sciences Building saltwater pool - ROV testing (and lots of salt) * OTC (Ocean Tech Center): another work location; more info coming soon™ We also often work remotely, sometimes synchronously in a call and sometimes asynchronously. There haven't been in-person "work parties" during the pandemic, but if this is something you want, be sure to bring it up! Anything is possible (well, not anything, but a lot). === What are our goals for Autumn 2021? === We have two primary overarching goals: * Everyone has a baseline ability to use CAD * Everyone has designed and made something with the 3D printer and the waterjet On a more technical/deliverable level, we will make: * Underwater camera system prototype * Pressure hold that can go in the water * Prototype for each mechanism on ROV (can be manually powered) == CAD (Onshape) == Our primary CAD & PDM system is Onshape. However, if you're more comfortable in another CAD system, feel free to use it and import data into Onshape for integration. === What is Onshape? === Onshape is a 3D MCAD (mechanical CAD) platform that runs in the cloud, with users accessing it through any modern web browser or the native apps on iOS and Android. Think of it as a crossover between Google Docs and SolidWorks. People can work on the same design simultaneously, and there are no files to manage. Plus, the heavy lifting happens in the cloud, so you can build significantly larger models, and the system cannot crash or lose data. === How do I get started? === # Sign up for a free education account [https://www.onshape.com/en/education/#form-container here] # If you don't have access to the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV Onshape team], send the email you're using with Onshape (e.g. myuwnetid@uw.edu) to Alnis (direct message @alnis#0001 on Discord or email alnis@uw.edu) # Bookmark [https://cad.onshape.com cad.onshape.com] for logging in (prevents having to search for it each time) # Get the [https://appstore.onshape.com/apps/Utilities/DFE73AMQ42NPMVAEQBQVP56QGLCWJ4ALJUBEBLA=/description link tab extension] so that you can embed wiki pages and other stuff in documents # Check out the introductory tutorials:<br />Never done CAD? [https://learn.onshape.com/learning-paths/introduction-to-cad Onshape CAD Basics]<br />Have experience? [https://learn.onshape.com/learning-paths/onshape-fundamentals-cad Onshape Fundamentals: CAD Learning Pathway] # Bookmark these resources:<br />[https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works)<br />[https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.)<br />[https://forum.onshape.com/ Official forum] (great practical modeling resource) === How is our CAD organized? === All of our documents live in the [https://cad.onshape.com/documents/t/60d41cc9de865b20e5ddf182 UWROV team] in Onshape. Ask Alnis for access to the team (alnis@uw.edu, @alnis#0001 on Discord). The folders are: * Common: parts libraries, templates, reusable components across years, etc. * Facilities: models of buildings, test stands, environments, workshops, etc. * Historical: CAD data from previous years (imported from other CAD systems) * ROV21: models for last year's ROV design * ROV22: models for our upcoming/current ROV design All UWROV documents must be in one of these folders to help keep things organized and ensure everyone has full editing permissions. == Project Management (monday.com) == Our monday.com team can be found here: https://uwrov.monday.com/ Please note that these processes will evolve over time as we find what does and doesn't work. === How are projects organized? === Projects are tracked in the Mechanical Project board: https://uwrov.monday.com/boards/1820040986 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Completed Projects''': all work done '''Active Projects''': not done, but being worked on '''Inactive Projects''': some work done, but no longer being worked on '''Potential Projects''': not started (might not be ready to be worked on) === How are tasks that haven't been started tracked? === They are prioritized, refined, and scheduled on the Mechanical Backlog board: https://uwrov.monday.com/boards/1608728974/views/32635707 For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Upcoming Iteration''': tasks we want to work on in the next month are moved here '''Ready''': everything needed to start is provided, and all fields are filled out '''Backlog''': tasks that need more refinement (requirements, detail, breaking down into smaller chunks, etc.) before they are ready to be worked on === How are in-progress tasks tracked? === Active tasks are tracked on the Mechanical Iterations board: https://uwrov.monday.com/boards/1405219881/ For information about what the columns mean, hover over the 🛈 (column description) symbol. '''Top group/iteration''': Currently active iteration cycle (timescale is roughly 1 month) '''Other groups''': Archive of previously completed work === What makes a good task? === '''Small''': Can be completed in one week or less '''Parallel''': Has as few dependencies as possible '''Actionable''': There is a clear place to start '''Measurable''': Clear success criteria/acceptance criteria (someone unfamiliar with the task can read it and know if it's done or not) == Google Drive == https://drive.google.com/drive/u/1/folders/0AI6SpxPjGd_GUk9PVA == Resources == Onshape: * [https://cad.onshape.com/help/ Help pages] (in-depth documentation of how everything works) * [https://learn.onshape.com/ Learning center] (tutorials, guides, articles, etc.) * [https://forum.onshape.com/ Official forum] (great practical modeling resource) Great YouTube channels: * [https://www.youtube.com/channel/UCj--iMtToRO_cGG_fpmP5XQ Munro Live] (fantastic videos about manufacturing and design) ** [https://youtu.be/ROOiCUfj9pw Elon & Sandy: Design Philosophy Parallels | PART 1] (fantastic overview of efficient design practices) ** [https://youtu.be/9bZGWOrDBpg Elon & Sandy: Design Philosophy Parallels | PART 2] (part 2, more about automation & production) * [https://www.youtube.com/c/BPSspace BPS.space YouTube channel] (build logs and informational videos for model rocketry) * [https://www.youtube.com/user/thang010146 thang010146 YouTube channel] (cool mechanisms) * [https://www.youtube.com/c/EVNautilus EVNautilus YouTube channel] (Nautilus Live ROV live streams etc.) Miscellaneous: * [https://www.youtube.com/c/3blue1brown 3Blue1Brown YouTube channel] (fantastic resource for linear algebra + other advanced math) * [https://youtu.be/XuL-_yOOJck From the Earth to the Moon - Mistakes Clip] (2 minute video from a movie about engineering mistakes) * [https://cad.onshape.com/documents/a43bc6ffbce7e900b8ba667d/w/86c500787f23eca298c5ac57/e/c5be007f13a2057bea015cad test link] (test link) https://cad.onshape.com/documents/a43bc6ffbce7e900b8ba667d/w/86c500787f23eca298c5ac57/e/c5be007f13a2057bea015cad bcefa4fec018353550091b313385cf3cc08cbc40